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(54) PROCEDE ET DISPOSITIF DE DETERMINATION D'AU MOINS UN IDENTIFICATEUR DE ROUTAGE D*AU 
MOINS UN PONT D'UN RESEAU. 

(57) L'invention concerne un procede de determination 
oau moins un identificateur d'au moins un pont (60, 61 , 62, 
63, 64, 65, 66, 67) reliant au moins une premiere partie d'un 
reseau (1 , 1 0) a au moins une deuxieme partie dudit reseau, 
caracterise en ce que ledit procede comporte les etapes 
suivantes: 

- determination d'au moins une caracteristique (ERW) 
du reseau, 

- determination d'au moins une caracteristique de ladite 
au moins une premiere partie du reseau (1, 10) a laquelle 
ledit pont est relie, 

- determination d'au moins une longueur d'au moins un 
identificateur (76, 77, 78, 79) associe a ladite au moins une 
premiere partie du reseau (1, 10) en fonction de ladite au 
moins une caracteristique de cette premiere partie et de la- 
dite au moins une caracteristique (ERW) du reseau, 

- affectation d'au moins un identificateur ayant une lon- 
gueur qui est celle venant d'etre determinee a au moins un 
pont (76, 77, 78, 79) relie a ladite au moins une premiere 
partie du reseau (1, 10). 
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10 La presente invention concerne un procede et un dispositif de 

determination d'au moins un identificateur d'au moins un pont reliant au moins 
une premiere partie d'un reseau a au moins une deuxieme partie dudit reseau. 

La presente invention concerne aussi bien le transfert 
d'informations entre deux parties d'un reseau qui sont des sous-reseaux de 
15 constitution et de performances differentes que le transfert d'information entre 
deux sous-reseaux de meme nature. 

Une partie d'un reseau est egalement appelee sous-reseau. 
On connaTt des reseaux de communication qui sont formes de 
plusieurs bus de communication serie conformes a la norme IEEE 1394. 
20 Ces bus sont organises en reseau, c'est-a-dire qu'ils sont relies 

entre eux par des equipements que Ton nomme des "ponts" ("bridges" en 
terminologie anglo-saxonne). 

On entend par pont tout equipement de liaison entre deux ou 
plusieurs parties d'un reseau. 
25 Le pont permet ainsi de transferer des paquets de donnees d'une 

premiere partie du reseau ou premier sous-reseau vers une deuxieme partie du 
reseau ou deuxieme sous-reseau par liaison filaire, optique, radio ou par tout 
autre type de liaison. 

Les ponts reliant entre eux des bus de communication serie font 
30 plus particulierement I'objet de la norme P1 394.1 qui est en cours de 
discussion. 
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Dans le cadre de cette norme, un pont est plus particulierement 
un equipement comportant au moins deux portions constitutives dudit pont, 
appelees "portals" en terminologie anglo-saxonne et permettant de relier entre 
eux au moins deux bus de communication serie 1394. Un "portal" est un 
5 ensemble de ports conformes a la norme 1394 et connectes a un bus de 
communication serie 1394. 

Chaque bus de communication serie d'un tel reseau relie 
differents peripheriques entre eux tels que des imprimantes, ordinateurs, 
serveurs, scanners, magnetoscopes, decodeurs (connus en terminologie anglo- 
10 saxonne sous le terme de "set top box"), televiseurs, cameras numeriques, 
camescopes, appareils photographiques numeriques... 

Ces peripheriques sont generalement appeles nceuds. 

Chaque peripherique situe sur un bus du reseau peut vouloir 
communiquer avec un autre peripherique du reseau situe sur un autre bus du 
15 reseau, les deux bus sur lesquels ces peripheriques sont situes etant separes 
par un ou plusieurs ponts. 

Ainsi, chacun de ces ponts sera done amene a transferer de 
maniere selective ou non les informations echangees entre les deux 
peripheriques depuis Tun des bus connecte a I'un des "portals" dudit pont vers 
20 un autre bus dispose de I'autre cote dudit pont et connecte a un autre "portal" 
de ce meme pont. 

Chaque bus peut etre connecte a plusieurs autres bus par 
I'intermediaire de plusieurs ponts differents. 

Lorsqu'un "portal" regoit un paquet de donnees il doit done pouvoir 
25 identifier si le paquet qu'il regoit est destine a un peripherique present sur son 
bus ou a un ou plusieurs des "portals" presents sur son bus. 

Pour ce faire, les informations vehiculees sur les differents bus du 
chemin que parcourt le paquet de donnees doivent indiquer la destination du 
paquet et chaque portal doit etre capable d'analyser cette destination pour 
30 transmettre les informations au peripherique destinataire. 
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Dans les reseaux conformes a la norme IEEE-1394, I'adresse de 
la destination est codee dans un premier champ d'informations dit 
d'identification de I'en-tete du paquet de donnees de longueur fixe, appele 
champ destination, et I'adresse de la source dudit paquet de donnees est 
5 codee dans un deuxieme champ d'informations dit d'identification de I'en-tete 
de longueur fixe, appele champ source. Ces deux champs sont distincts et leur 
longueur depend du protocole de communication. 

Dans les reseaux conformes a la norme IEEE-1394, le champ 
destination est par exemple code sur 16 bits et le champ source egalement. 
10 Ces 16 bits sont separes en 10 bits reserves au codage de Ndentificateur du 
bus sur lequel se trouve le peripherique destinataire du paquet de donnees et 6 
bits reserves au codage de I'identificateur du peripherique destinataire sur ce 
bus. 

De tels reseaux de transfert de paquets de donnees necessitent 
15 un equipement centralise {connu sous le terme "prime portal" en terminologie 
anglo-saxonne) qui, lors de I'initialisation du reseau, va attribuer un numero a 
chaque bus du reseau. Ensuite, apres cette etape de numerotation 
automatique, chaque "portal" de chaque pont va configurer une table de 
routage qui lui est propre en fonction des differents messages qu'il aura vu 
20 passer. 

Cette table de routage est par exemple representee par une 
succession de bits ou chaque bit correspond a un bus du reseau. 

Chaque bit sera positionne a la valeur binaire 0 ou 1, 0 si le pont 
ne doit pas transferer des donnees destinees a un peripherique present sur le 
25 bus correspondant a ce bit dans la table et 1 si le pont doit transferer des 
donnees destinees a un peripherique present sur le bus correspondant a ce bit 
dans la table. 

Ces reseaux sont configures pour pouvoir interconnecter un 
nombre maximal de 1024 bus. Chaque table de routage doit done comporter 
30 1023 bits et chaque pont doit done comporter deux tables de routage de 1023 
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bits puisque chaque portal est relie a des bus differents et doit done, de ce fait, 
posseder sa propre table. 

Dans un tel reseau, lorsque le paquet de donnees arrive dans le 
pont, celui-ci lit le champ destination place dans I'en-tete de ce paquet de 
5 donnees et lit sa table de routage afin de determiner s'il peut transmettre le 
paquet au bus destinataire, e'est-a-dire si le bit correspondant a ce bus est 
positionne a "1" dans la table de routage. 

Ces reseaux de transfert de paquets de donnees presentent 
plusieurs inconvenients, a commencer par la complexity des mecanismes de 
10 configuration, aussi bien pour I'attribution des numeros de bus que pour la 
gestion de ces numeros dans la table de routage. 

En outre, ces reseaux necessitent une gestion centralisee qui doit 
determiner, lors de ('initialisation du reseau, la topologie dudit reseau, e'est-a- 
dire la facon dont sont relies entre eux les differents bus. Pour ce faire, il est 
15 necessaire d'etablir un protocole d'echange entre les differents bus afin de 
mettre en place cette gestion centralisee. 

Ces reseaux doivent attribuer un numero a chaque bus et ce 
numero est unique dans un reseau donne. 

II convient de noter que lorsque deux reseaux sont interconnects 
20 par un pont afin de former un seul et meme reseau, chaque reseau formant 
une partie dudit reseau final, il faut d'abord elire celui des deux equipements 
centralises ou "prime portals" des deux reseaux qui va devenir I'equipement 
centralise ou "prime portal" du reseau final. 

Ensuite, etant donne qu'un numero a deja ete attribue a chaque 
25 bus de chaque reseau prealablement a leur reunion, la numerotation de 
chaque bus devra done etre corrigee pour garder I'unicite de numerotation des 
bus et toutes les tables de routage devront etre reconfigurees. 

Par ailleurs, ces reseaux generent des trafics d'informations dites 
protocolaires d'autant plus importants que lesdits reseaux sont constitues d'un 
30 nombre important d'elements, ce qui penalise considerablement la capacite du 
reseau a vehiculer des informations utiles pour les peripheriques dudit reseau. 
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On connaTt des precedes de transfert de paquets de donnees tels 
que celui decrit dans le brevet US 5 442 881, permettant de coder I'en-tete a la 
source. Le peripherique ou nceud source qui veut emettre un paquet de 
donnees connaTt le chemin qui le separe du peripherique destinataire auquel il 
5 veut transferer des donnees. Ce chemin est code dans un champ de I'en-tete 
du paquet de donnees qui comporte toutes les adresses ou identifications des 
differents noeuds du reseau rencontres par ledit paquet de donnees sur son 
chemin. 

Lorsqu'un equipement de ce r6seau, charge du transfert des 
10 paquets, regoit le paquet de donnees, il decode cet en-tete et transmet le 
paquet au peripherique destinataire apres avoir modifie cet en-tete. 

On connaTt egalement le brevet US 5 613 069 qui decrit un 
procede de transfert de paquets dans un reseau a commutation de paquets, 
chaque paquet comprenant un champ d'en-tete de longueur variable pour 
15 decrire le chemin a parcourir ainsi qu'un champ de fin de paquet de longueur 
variable pour decrire le chemin parcouru. 

Toutefois, ce systeme s'applique a la commutation de paquets ou 
chaque port d'un commutateur est relie a un seul autre port d'un autre 
commutateur alors qu'un pont peut etre relie a plusieurs autres ponts via un 
20 meme bus. 

Ainsi, une telle solution n'est pas adaptee a etre mise en ceuvre 
dans un reseau du type de ceux presentes ci-dessus, conformes a la norme 
IEEE 1394. Dans ces reseaux, I'en-tete de chaque paquet de donnees 
comporte un champ destination et un champ source, dont 10 bits seulement 

25 sont reserves dans chacun d'eux au codage de Pidentificateur du bus sur lequel 
se trouve le peripherique destinataire ou source. 

En effet, dans un reseau du type conforme a la norme IEEE 1394, 
dans le cas ou le nombre maximal autorise de chaque portion constitutive d'un 
pont ou "portal" sur un bus est de trois, il faut au minimum deux bits pour coder 

30 I'adresse ou I'identificateur de chaque "portal" de facon unique. 
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Le champ destination de I'en-tete des paquets de donnees peut 
done contenir quatre identificateurs de "portals" differents. 

Ainsi le nombre maximal de ponts separant la source et la 
destination est done, dans cet exemple, de quatre. 
5 Ceci est restrictif et Ton constate que plus le nombre de "portals" 

autorises sur un bus augmente, plus il est necessaire d'avoir un nombre eleve 
de bits pour coder I'identificateur de ces portals et done plus la distance 
maximale entre la source d'un paquet de donnees et sa destination est faible. 

Par ailleurs, la Demanderesse s'est apercue que, dans un tel 
10 reseau, on ne tient pas compte des specificites de chaque bus constituant le 
reseau. 

En effet il existe des bus possedant des caracteristiques ayant 
differentes performances, par exemple des bus pouvant transmettre des debits 
de 100, 400 voire 800 Mbps/s ou plus. Or, une caracteristique importante pour 
15 le transfert de paquet telle que le debit n'est pas prise en compte lors du 
transfert de paquets a travers differentes parties de reseaux ou sous-reseaux 
tels que des bus, ce qui peut induire de graves probiemes de congestion du 
reseau, limitant par la meme le debit total du reseau done des performances de 
celui-ci. 

20 De plus, certains bus sont relies a un nombre eleve d'autres bus 

par I'intermediaire de ponts. Ces meme bus, en raison de leur multiples liens 
avec d'autres parties de reseaux ou sous-reseaux, risquent de devoir transferer 
un nombre plus eleve d'informations que d'autres bus. 

II s'ensuit done egalement des probiemes de congestion de 

25 reseaux. 

D'une maniere generate, la Demanderesse s'est apercue, de 
facon tout a fait inattendue, que les identificateurs de ponts sont determines 
dans le reseau de maniere inappropriee. 

La presente invention vise a remedier a au moins un des 
30 inconvenients precites en proposant un precede de determination d'au moins 
un identificateur d'au moins un pont reliant au moins une premiere partie d'un 
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reseau a au moins une deuxieme partie dudit reseau, caracterise en ce que 
ledit procede comporte les etapes suivantes : 

- determination d'au moins une caracteristique du reseau, 

- determination d'au moins une caracteristique de ladite au moins 
5 une premiere partie du reseau a laquelle ledit pont est relie, 

-determination d'au moins une longueur d'au moins un 
identificateur associe a ladite au moins une premiere partie du reseau en 
fonction de ladite au moins une caracteristique de cette premiere partie et de 
ladite au moins une caracteristique du r6seau, 
10 -affectation d'au moins un identificateur ayant une longueur qui 

est celle venant d'etre determinee a au moins un pont relie a ladite au moins 
une premiere partie du reseau. 

Correlativement, I'invention vise un dispositif de determination 
d'au moins un identificateur d'au moins un pont reliant au moins une premiere 
1 5 partie d'un reseau a au moins une deuxieme partie dudit reseau, caracterise en 
ce que ledit dispositif comporte : 

- des moyens de determination d'au moins une caracteristique du 

reseau, 

- des moyens de determination d'au moins une caracteristique de 
20 ladite au moins une premiere partie du reseau a laquelle ledit pont est relie, 

- des moyens de determination d'au moins une longueur d'au 
moins un identificateur associe a ladite au moins une premiere partie du reseau 
en fonction de ladite au moins une caracteristique de cette premiere partie et 
de ladite au moins une caracteristique du reseau, 

25 - des moyens d'affectation d'au moins un identificateur ayant une 

longueur qui est celle venant d'etre determinee a au moins un pont relie a ladite 

au moins une premiere partie du reseau. 

La demanderesse s'est apercue qu'en affectant a au moins un 

pont relie a une partie du reseau un identificateur dont la longueur a ete 
30 determinee en fonction d'au moins une caracteristique propre a cette partie du 

reseau ainsi que d'au moins une caracteristique du reseau, on ameliore la 
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gestion des ressources du reseau et, notamment les identificateurs des ponts 
du reseau sont mieux adaptes aux particularit.es du reseau qu'auparavant. 

Ainsi, la longueur d'un identificateur est ajustee pour eviter les 
problemes de congestion et, par exemple, permet d'augmenter le nombre de 
5 ponts pouvant etre traverses par un paquet de donnees et/ou d'augmenter le 
nombre de ponts connectes a un meme bus. 

Cette affectation d'identificateur permet egalement une utilisation 
optimale quant a la performance en debit de chaque partie ou sous-reseau du 
reseau. 

10 Le fait de considerer au moins une caracteristique d'une partie ou 

sous-reseau du reseau dans la determination de la longueur de I'identificateur 
ou label d'un pont permet d'ameliorer la performance de cette partie du reseau 
et de garantir une transmission d'information dans le reseau au meilleur debit. 

Cette simple evaluation locale illustre la simplicity de I'etape 
15 d'affectation de I'identificateur de pont dans le reseau selon I'invention. 

Grace a I'invention, il n'est pas necessaire de configurer des 
tables de routage et il n'y a pas de problemes lies a ('interconnexion de 
plusieurs parties ou sous-reseaux d'un reseau. 

Avantageusement, le precede de determination selon I'invention 
20 n'est pas centralise, mais il est, au contraire, mis en oeuvre localement sur au 
moins une partie ou sous-reseau. L'invention permet done d'eviter une gestion 
complexe et un echange protocolaire important. 

Selon une caracteristique, au moins un identificateur est affecte 
audit pont reliant lesdites premiere et deuxieme parties du reseau, ledit pont 
25 etant un element essentiel du reseau. 

Selon une caracteristique, ledit pont comportant au moins deux 
portions reliees chacune auxdites au moins deux parties du reseau, au moins 
un identificateur est affecte a chacune desdites au moins deux portions. 

Ainsi, I'affectation est faite a chaque element du pont et permet 
30 done de differencier les traitements entre chaque partie ou sous-reseau, ce qui 
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a pour consequence, d'offrir une meilleure gestion de chaque partie ou sous- 
reseau. 

Selon une caracteristique, led it pont est relie a au moins un bus 
de communication serie. 
5 Selon une autre caracteristique liee a celle qui precede, chaque 

identificateur est unique pour un bus de communication serie donne. 

Ceci permet de simplifier le traitement et le codage de I'en-tete a 

la source. 

De ce fait, le mecanisme d'initialisation est local a un bus, ce qui 
10 ne necessite pas d'echange au-dela des ponts pour la configuration du reseau 
en ce qui concerne le precede de transfert de paquets. 

Selon une caracteristique particuliere de I'invention I'etape de 
determination d'au moins une caracteristique de ladite au moins une premiere 
partie du reseau consiste a determiner le debit binaire possible de ladite partie. 
15 Le debit binaire est un critere important lorsque Ton s'interesse 

aux problemes de congestion. 

Ainsi, des reseaux de performances en debit superieures a celles 
d'autres reseaux se verront attribuer une longueur ou taille d'identificateur 
differente de celle desdits autres reseaux. 
20 Selon un mode de realisation prefere, I'etape de determination de 

la longueur de I'identificateur debouchera sur une longueur d'identificateur 
superieure a celle necessaire pour coder tous les ponts a un instant donne. 
Ceci permet en effet a un plus grand nombre de ponts de pouvoir etre lies audit 
sous-reseau augmentant ainsi les possibilites d'echange entre ledit sous- 
25 reseau vers d'autres sous-reseaux constituant ledit reseau. 

Selon une autre caracteristique de I'invention I'etape de 
determination d'une caracteristique de ladite au moins une premiere partie du 
reseau consiste a determiner le nombre de ponts relies a celle-ci. 

Ceci permet de maniere simple et adaptative de pouvoir mettre en 
30 oeuvre un precede de transfert de paquets utilisant un codage a la source de 
maniere flexible. Ce codage a la source flexible est transparent pour I'utilisateur 
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qui n'a pas a considerer la facon d'interconnecter differentes parties ou sous- 
reseaux d'un reseau, une telle interconnexion etant faite automatiquement par 
chaque partie du reseau ou sous-reseau et son (ou ses) pont(s) associe(s). 

Ceci permet d'affecter la taille ou longueur de I'identificateur de 
5 facon appropriee de maniere a maximiser la distance entre source et 
destination. 

Selon une caracteristique, I'etape d'affectation d'au moins un 
identificateur est effectuee pour chaque pont relie a ladite au moins une 
premiere partie du reseau. 
10 Ainsi, tous les ponts sont identifies et tous les chemins a travers 

les ponts sont possibles. 

Selon une caracteristique, I'etape d'affectation d'au moins un 
identificateur est effectuee pour un nombre maximum predetermine de ponts 
relies a ladite au moins une premiere partie du reseau. 
15 Cette caracteristique permet de limiter le nombre de ponts sur un 

bus, done le nombre d'interconnexions, et par la meme de resoudre le 
probleme de congestion. 

Selon une caracteristique, le nombre maximal (MBNB) 
predetermine de ponts est egal a (2 ERW -1 ) max - width/ERW 0 u max-width represente le 
20 nombre de bits maximal pour coder un identificateur sur le reseau. 

Ceci permet une utilisation optimale des capacites de la longueur 
de ridentificateur, done du nombre de ponts qu'il est possible de connecter au 
bus. 

Selon une caracteristique, la caracteristique ERW du reseau 
25 correspond a la plus petite longueur possible d'identificateur de pont dans le 
reseau. 

Selon une autre caracteristique liee a la caracteristique 
precedents, la longueur dudit au moins un identificateur associe a ladite au 
moins une premiere partie du reseau est egale a un multiple de la plus petite 
30 longueur d'identificateur ERW. 
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Ainsi, les differents champs d'informations constituant Pen-tete 
d'un paquet de donnees et comportant les identificateurs des ponts rencontres 
par le paquet seront alignes sur des multiples de la plus petite longueur ERW, 
ce qui facilitera le traitement de Pen-tete dudit paquet au niveau de chaque 
5 pont. 

Selon une caracteristique, le procede comporte une etape 
d'ajustement, en fonction de la caracteristique ERW du reseau, de la longueur 
d'un marqueur delimitant, dans un paquet de donnees transfere dans le 
reseau, un premier champ d'informations d'identification du chemin a parcourir 

10 par ledit paquet dans le reseau d'un deuxieme champ d'informations 
d'identification du chemin parcouru par ce paquet. La longueur du marqueur est 
ainsi ajustee en fonction de la taille ou longueur des chemins a parcourir et 
parcouru par le paquet pour maintenir une longueur fixe de I'ensemble des 
champs et du marqueur. 

15 Plus particulierement, la longueur du marqueur est ajustee a la 

plus petite longueur ERW. 

La taille ou longueur du marqueur se trouve de ce fait reduite ce 
qui laisse davantage de bits dans Pen-tete des paquets de donnees pour coder 
un ou des identificateurs de ponts supplementaires entre la source des paquets 

20 et leur destination. 

Selon une caracteristique, le marqueur comporte une suite 
predeterminee de bits. 

Selon une caracteristique liee a la precedente, chaque pont relie a 
ladite au moins une premiere partie du reseau se voit affecte au moins un 

25 identificateur sous la forme d'une suite de bits choisie parmi un ensemble de 
valeurs ne contenant pas la suite predeterminee de bits correspondant au 
marqueur. Ceci permet de simplifier ('identification du marqueur dans I'en-tete 
du paquet de donnees lors du traitement de cet en-tete au niveau d'un pont. 

Selon une caracteristique, le procede comporte une etape 

30 d'identification du marqueur dans un paquet de donnees transfere dans le 
reseau, les deux champs d'informations d'identification de chemin ainsi que le 
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marqueur etant representes sous la forme d'une serie de bits consecutifs et 
ladite etape d'identification dudit marqueur parmi cette serie de bits comportant, 
plus particulierement, une etape de lecture des bits groupes suivant une 
longueur egale a un multiple entier de la caracteristique ERW. 
5 (-'identification du marqueur dans I'en-tete du paquet de donnees 

est ainsi simplifiee et plus rapide lors du traitement de cet en-tete au niveau 
d'un pont. 

Selon une caracteristique, ledit paquet de donnees comporte au 
moins deux champs d'informations dits d'identification du chemin 
10 respectivement a parcourir et parcouru par ledit paquet de donnees, lesdits au 
moins deux champs d'information ayant chacun une longueur donnee, ledit 
precede comportant les etapes suivantes lors du transfert dudit paquet de 
donnees a travers ledit pont : 

- suppression d'au moins une premiere information d'au moins un 
15 premier champ d'informations, reduisant ainsi la longueur dudit premier champ 

d'informations d'une longueur correspondant a cede de ladite premiere 
information, 

- ajout d'au moins une deuxieme information dans au moins un 
deuxieme champ d'informations, augmentant ainsi la longueur dudit deuxieme 

20 champ d'informations d'une longueur correspondant a celle de ladite deuxieme 
information. 

Ceci permet, en utilisant un codage a la source, d'augmenter 
I'espace disponible pour coder le chemin du paquet. 

Selon une caracteristique, le paquet de donnees comporte deux 
25 extremite opposees et lesdits au moins deux champs d'informations sont situes 
a une meme extremite dudit paquet de donnees. 

Ainsi, les informations sont avantageusement concentrees en un 
meme espace, ce qui permet de respecter la norme IEEE 1394. 

Selon une caracteristique, le paquet de donnees comporte un 
30 troisieme champ d'informations dit marqueur qui delimite les premier et 
deuxieme champs d'informations I'un par rapport a I'autre. 
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Ceci permet de faciliter le traitement concernant la lecture de I'en- 
tete du paquet et apporte simplicite et efficacite a ce traitement. 

Avantageusement, le marqueur permet de determiner qu'un 
champ est sur le point d'etre totalement consomme par suite des suppressions 
5 consecutives d'informations dans ledit champ a chaque traversee d'un pont. Le 
marqueur sert ainsi au dernier bus pour savoir que le peripherique destinataire 
est sur ledit bus. 

Selon une caracteristique, le marqueur a une longueur au moins 
egale au nombre de bits necessaire pour coder un identificateur dudit pont 
1 0 dans I'un des champs d'informations. 

Cette caracteristique presente le meme avantage que celui 
mentionne precedemment. 

Selon une caracteristique, le procede comporte, lors du transfert 
dudit paquet de donnees a travers ledit pont, une etape de decalage des 
15 premier, deuxieme et troisieme champs d'informations entre les etapes de 
suppression et d'ajout d'informations. 

Ainsi, le marqueur est deplace apres chaque passage au travers 
d'un pont et sa position varie quant a sa taille en fonction de la distance 
(exprimee en nombre de ponts traverses) parcourue par le paquet entre la 
20 source et la destination. 

Selon une caracteristique, la longueur totale des premier, 
deuxieme et troisieme champs est fixe. 

Selon une caracteristique, le procede comporte, lors du transfert 
dudit paquet de donnees a travers ledit pont, une etape de comparaison de la 
25 longueur de I'un des premier et deuxieme champs d'informations d'identification 
du paquet recu de ladite au moins une premiere partie du reseau avec la 
longueur du meme champ du paquet transmis sur ladite au moins deuxieme 
partie du reseau. 

Plus particulierement, lorsque la longueur de I'un des premier et 
30 deuxieme champs d'informations d'identification du paquet recu de ladite au 
moins une premiere partie du reseau est differente de la longueur du meme 
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champ du paquet transmis sur ladite au moins une deuxieme partie du reseau, 
ledit precede comporte une etape de modification de la longueur du troisieme 
champ du paquet a transmettre. 

Ceci permet de garantir une taille d'en-tete fixe et de pouvoir 
5 transferer dans un champ de taille fixe des identificateurs de pont de taille 
differentes. 

Ainsi, et de maniere avantageuse, la coexistence d'identificateurs 
de taille differente dans un meme reseau est rendue realisable dans un champ 
de longueur fixe. 

10 Selon une caracteristique, la longueur de Tun des premier et 

deuxieme champs d'informations d'identification du paquet recu de ladite au 
moins une premiere partie du reseau est egale a la longueur du meme champ 
du paquet transmis sur ladite au moins une deuxieme partie. 

Ainsi, la gestion du reseau est tres simple et satisfait a la norme 

15 IEEE 1394. 

Selon une caracteristique, lesdits premier et deuxieme champs 
d'informations contiennent des informations relatives audit au moins un 
identificateur du ou des ponts disposes sur le chemin du paquet de donnees 
dans le reseau. 

20 Ceci permet d'utiliser un codage de l'en-t£te a la source. 

Le routage a la source simplifie en effet la mise en oeuvre du 
routage dans les ponts intermediates places entre la source et la destination 
du paquet. 

Selon une caracteristique, ledit premier champ d'informations 
25 contient des informations relatives audit au moins un identificateur du ou des 
ponts disposes sur le chemin a parcourir par le paquet de donnees dans le 
reseau. 

Selon un deuxieme aspect, Pinvention concerne un precede de 
determination d'au moins un identificateur d'au moins un pont reliant au moins 
30 une premiere partie d'un reseau a au moins une deuxieme partie dudit reseau, 
caracterise en ce que ledit precede comporte les etapes suivantes : 
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determination d'au moins une caracteristique de ladite au 
moins une premiere partie du reseau a laquelle ledit pont est relie, 

determination d'au moins une longueur d'au moins un 
identificateur associe a ladite au moins une premiere partie du reseau en 
5 fonction de ladite au moins une caracteristique de cette premiere partie et d'au 
moins une caracteristique du reseau, 

affectation d'au moins un identificateur ayant une longueur qui 
est celle venant d'etre determinee a au moins un pont relie a ladite au moins 
une premiere partie du reseau. 
10 Un tel precede est mis en ceuvre au niveau d'un pont du reseau. 

Correlativement, I'invention concerne egalement un dispositif de 
determination d'au moins un identificateur d'au moins un pont reliant au moins 
une premiere partie d'un reseau a au moins une deuxieme partie dudit reseau, 
caracterise en ce que ledit dispositif comporte : 
15 - des moyens de determination d'au moins une caracteristique 

de ladite au moins une premiere partie du reseau a laquelle ledit pont est relie, 
des moyens de determination d'au moins une longueur d'au 
moins un identificateur associe a ladite au moins une premiere partie du reseau 
en fonction de ladite au moins une caracteristique de cette premiere partie et 
20 d'au moins une caracteristique du reseau, 

des moyens d'affectation d'au moins un identificateur ayant 
une longueur qui est celle venant d'etre determinee a au moins un pont relie a 
ladite au moins une premiere partie du reseau. 

Selon un troisieme aspect, I'invention vise un pont reliant au 
25 moins deux parties d'un reseau de communication de paquets de donnees 
entre elles, caracterise en ce que ledit pont comporte un dispositif de 
determination d'au moins un identificateur d'au moins un pont comme expose 
ci-dessus. 

Selon un quatrieme aspect, I'invention vise un appareil de 
30 traitement des donnees, caracterise en ce qu'il comporte un pont conforme au 
bref expose qui precede. 
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L'appareil de traitement est, par exempie, une imprimante. 

L'appareil de traitement est, par exempie, un serveur. 

L'appareil de traitement est, par exempie, un ordinateur. 

L'appareil de traitement est, par exempie, un telecopieur. 

L'appareil de traitement est, par exempie, un scanner. 

L'appareil de traitement est, par exempie, un magnetoscope. 

L'appareil de traitement est, par exempie, un decodeur (connu en 
terminologie anglo-saxonne sous le terme de "set top box"). 

L'appareil de traitement est, par exempie, un televiseur. 

L'appareil de traitement est, par exempie, un camescope. 

L'appareil de traitement est, par exempie, une camera numerique. 

L'appareil de traitement est, par exempie, un appareil 
photographique numerique. 

Selon un cinquieme aspect, I'invention vise un reseau de 
communication de paquets de donnees comportant au moins deux parties 
reliees entre elles par au moins un pont, caracterise en ce que ledit pont est 
conforme a ce qui precede. 

Selon une caracteristique particuliere, chacune desdites au moins 
deux parties dudit reseau comporte au moins un bus de communication serie 
auquel est relie ledit pont. 

Selon un sixieme aspect, I'invention vise un reseau de 
communication de paquets de donnees comportant au moins deux parties 
reliees entre elles par au moins un pont, caracterise en ce que ledit reseau 
comporte un appareil de traitement de donnees tel que brievement expose ci- 
dessus. 

L'invention vise par ailleurs un moyen de stockage d'informations, 
eventuellement totalement ou partiellement amovible, lisible par un ordinateur 
ou un processeur contenant des instructions d'un programme informatique, 
caracterise en ce qu'il permet la mise en oeuvre du precede de determination 
d'au moins un identificateur d'au moins un pont tel que brievement expose ci- 
dessus. 
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L'invention vise en outre un moyen de stockage d'informations, 
eventuellement totalement ou partiellement amovible, lisible par un ordinateur 
ou un processeur contenant des donnees provenant de la mise en ceuvre du 
precede de determination d'au moins un identificateur d'au moins un pont tel 
5 que brievement expose ci-dessus. 

L'invention vise egalement une interface permettant de recevoir 
les instructions d'un programme informatique, caracterise en ce qu'il permet la 
mise en oeuvre du precede de determination d'au moins un identificateur d'au 
moins un pont dans un reseau tel que brievement expose ci-dessus. 

10 Les avantages et caracteristiques propres au dispositif de 

determination d'au moins un identificateur d'au moins un pont, au pont reliant 
au moins deux parties d'un reseau entre elles et comportant un tel dispositif, a 
I'appareil de traitement de donnees comportant un tel pont, audit reseau 
comportant un tel pont et audit reseau comportant un tel appareil de traitement 

15 de donnees, ainsi qu'aux moyens de stockage d'informations etant les memes 
que ceux exposes ci-dessus concernant le precede de determination d'au 
moins un identificateur d'au moins un pont selon l'invention, ils ne seront pas 
rappeles ici. 

D'autres caracteristiques et avantages apparaTtront au cours de la 
20 description qui va suivre donnee a titre d'exemple illustratif et non limitatif, et 
faite en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue schematique d'un reseau de bus de 
communication serie ; 

- la figure 2 est une vue schematique representant la structure 
25 d'un paquet de donnees asynchrone tel que defini dans la norme IEEE 1394- 

95; 

- la figure 3 est une vue schematique detaillee d'un appareil de 
traitement de donnees comportant un pont reference 66 sur la figure 1 ; 

- la figure 4 est une vue schematique representant differents 
30 registres stockes dans la memoire RAM de I'appareil de traitement de donnees 

de la figure 3 ; 



18 



2805370 



- la figure 5 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont intermediate reference 66 sur la figure 1 ; 

- la figure 6 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont destinataire reference 67 sur la figure 1 ; 

- la figure 7 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont source reference 67 sur la figure 1 ; 

- la figure 8 est une vue schematique detaillee representant une 
table de routage stockee dans la memoire RAM de I'appareil de traitement de 
donnees de la figure 3 ; 

- les figures 9 et 10 represented une vue schematique des 
algorithmes des precedes, d'une part, de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage et, d'autre part, de 
recuperation d'un index a partir d'un descripteur de chemin ; 

- la figure 11 est une vue schematique de I'algorithme d'un 
procede de transfert de paquets ; 

- la figure 12 est une vue schematique d'un reseau de bus lors de 
la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part ; 

- la figure 13 est une vue schematique representant la structure 
d'un paquet de donnees de resolution d'adresse ; 

- la figure 14 est une vue schematique representant la structure 
d'un paquet de donnees asynchrone de reponse au paquet decrit en figure 13 ; 

- la figure 15 est une vue schematique detaillee representant une 
table de verification stockee dans la memoire RAM de la figure 3 ; 

- la figure 16 est une vue schematique de I'algorithme d'un 
procede de reception d'un paquet de resolution d'adresse au niveau d'un 
equipement d'interconnexion d'un pont ; 

- la figure 17 est une vue schematique de I'algorithme d'un 
procede de reception d'un paquet de donnees de reponse au paquet de 
resolution d'adresse au niveau d'un equipement d'interconnexion d'un pont ; 
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- les figures 18 et 20 sont des vues schematiques de I'algorithme 
d'un procede de determination d'identificateurs ou labels de routage au niveau 
d'un bus en fonction de la capacite du bus; 

- les figures 19 et 21 sont des vues schematiques de I'algorithme 
5 d'un procede de determination d'identificateurs ou labels de routage au niveau 

d'un bus en fonction du nombre de ponts connectes sur le bus. 



La figure 1 represente une vue schematique d'un reseau de bus 
de communication serie dans le cadre duquel s'applique ('invention. Un 
10 ensemble de bus de communication serie 51, 52, 53, 54, 55, 56, 57, 58 et 59, 
interconnects par plusieurs ponts 60, 61, 62, 63, 64, 65, 66 et 67, permettent 
a des peripheriques situes sur des bus differents d'echanger des paquets de 
donnees asynchrones. 

Ainsi, un peripherique 68, connecte au bus 52, peut initier une 
15 transaction avec un peripherique 69 qui, lui, se trouve connecte au bus 59, par 
echanges de paquets asynchrones. Le transfert de paquets d'un bus a I'autre 
est assure par un procede de transfert de paquets. 

La structure d'un paquet asynchrone, largement decrite dans la 
norme IEEE 1394-95, est illustree a la figure 2. Les paquets asynchrones sont 
20 entre autre utilises pour effectuer des transactions entre un peripherique source 
et un peripherique destination. Une transaction est effectuee en emettant un 
paquet de type "Requete" de la source vers la destination, puis un paquet de 
type "Reponse" de la destination vers la source. 

Le champ "destinationJD" 80 de la figure 2 ("Destination 
25 Identifier" en terminologie anglo-saxonne), represente sur 16 bits, contient 
I'information de routage permettant d'atteindre le peripherique destination. Ce 
champ est compose de deux sous champs 80a "destination_Bus_ID" 
represente sur 10 bits et 80b "destination_Node_ID" represente sur 6 bits. 

Le champ 80a est appele champ d'informations d'identification du 
30 chemin a parcourir par le paquet de donnees. 
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Le champ "sourceJD" 81 ("Source Identifier" en terminologie 
anglo-saxonne), represents sur 16 bits, contient reformation de routage 
permettant d'atteindre le pSriphSrique source. Ce champ est compose de deux 
sous champs 81a "source_Bus_ID" represents sur 10 bits et 81b 
5 "source_Node_ID" represents sur 6 bits. 

Le champ 81a est appele champ d'informations d'identification du 
chemin parcouru par le paquet de donnSes. 

La presence de ces deux champs 80 et 81 favorise le 
dSroulement d'une transaction entre la source et la destination. 
10 II convient de noter que les deux champs d'informations 

d'identification d'un paquet de donnees ne sont pas necessairement places 
dans I'en-tete dudit paquet, comme c'est la cas dans cet exemple, mais 
peuvent etre situes a I'extremite opposee de ce paquet, c'est-a-dire en fin de 
paquet. 

15 Le champ "tl" 82 ('Transaction Label" en terminologie anglo- 

saxonne), represents sur 6 bits, permet de numSroter une transaction entre des 
pSripheriques. 

Le champ "rt" 83 ("Retry Code" en terminologie anglo-saxonne), 
reprSsentS sur 2 bits, permet d'identifier les tentatives d'Smission d'un meme 
20 paquet asynchrone. 

Le champ "tcode" 84 ("Transaction Code" en terminologie anglo- 
saxonne), represents sur 4 bits, permet d'identifier un type de paquet 
asynchrone, tel que par exemple le type de la transaction. 

Le champ "pri" 85 ("Priority" en terminologie anglo-saxonne), 
25 represents sur 4 bits, permet d'identifier la prioritS associSe au paquet 
asynchrone. 

Les champs 86, 87, 88, 89 et 90 sont pour certains optionnels et 
sont relatifs a I'interprStation des donnSes vShiculSes par le paquet 
asynchrone. 

30 La figure 3 represente la structure schSmatique d'un appareil de 

traitement de donnees tel qu'un ordinateur 11 comportant, par exemple, le pont 
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66 represents a la figure 1. Ainsi, tous les ponts du reseau representes a la 
figure 1 ont par exemple cette structure. 

L'appareil de traitement de donnees pourrait egalement prendre la 
forme d'une imprimante, d'un serveur, d'un telecopieur, d'un scanner, d'un 
magnetoscope, d'un decodeur (connu en terminologie anglo-saxonne sous le 
terme de "set-top box"), d'un televiseur, d'un camescope, d'une camera 
numerique ou d'un appareil photographique numerique. 

Tous les ponts de la figure 1 peuvent etre par exemple etre 
integres dans un appareil de traitement de donnees de ce type ou bien 
constituer l'appareil lui-meme. 

Le pont constitue, dans cet exemple, un dispositif de transfert de 
paquets. Ce pont comporte une unite de calcul CPU 12, une memoire de 
stockage permanent 14 (ROM) qui contient les differentes instructions des 
algorithmes representes aux figures 9, 10, 11, 16, 17, 18, 19, 20 et 2 let une 
memoire de stockage temporaire 16 (RAM). Ces trois elements 12, 14 et 16 
communiquent au moyen de bus d'adresses et de donnees respectifs notes 18, 
20, 22, avec un bloc note 24 et connu de I'homme de I'art sous le nom de pont 
PCI. 

L'ordinateur 11 comporte egalement un ecran 13, un clavier 15, 
un lecteur de disquettes 17, un lecteur de CD-ROM 19 et une interface reseau 
21 (figure 3). 

L'interface reseau 21 peut recevoir, par exemple, par 
I'intermediaire d'un reseau local (non represents) de type Ethernet les 
instructions d'un programme informatique permettant la mise en ceuvre au 
niveau d'un pont du procede selon I'invention. 

De telles instructions peuvent egalement etre contenues dans une 
disquette inseree dans le lecteur de disquettes ou dans un CD-ROM insere 
dans le lecteur de CD-ROM. 

Le bloc 24 est en fait un ensemble de composants PCI tel que 
I'ensemble Intel 440LX AGP ("Intel 440LX AGPset" dans la terminologie anglo- 
saxonne) commercialise par la societe INTEL. Ainsi, le bloc 24 comporte, par 
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exemple, un composant 82443LX (non represents) qui assure I'interface avec 
la memoire 16 via le bus memoire 22 et avec ('unite de calcul CPU 12 via le bus 
local 18. Le composant 82443LX est lui-meme reliS a un composant 82371 AB 
(non represents) qui fournit une interface avec le bus ISA 20 relie a la memoire 
5 14 et aux differentes extensions de pSriphSriques : Scran 13, clavier 15, lecteur 
de disquette 17, lecteur de CD-ROM 19 et interface de reseau 21. Un 
contrdleur d'interruption IOAPIC Intel 82093AA (non represents) connects a 
I'unitS de calcul CPU 12 gere les interruptions pouvant survenir dans le 
systeme. 

10 Ce bloc 24 permet notamment d'Schanger des donnSes au moyen 

du bus standard PCI 26 (PCI signifiant en terminologie anglo-saxonne 
"Peripheral Component Interconnect") avec un autre composant d'interface PCI 
note 28. Le bus 26 peut egalement connecter entre eux d'autres SISments, non 
representes sur la figure, eux-memes pourvus d'une interface PCI et pouvant 
1 5 mettre en ceuvre par exemple des fonctions de traitement de donnSes. 

Le composant 28 est un composant dSnommS AMCC5933QC et 
est commercialise par la societS Applied Micro Circuits Corporation. 

II convient de noter que le dispositif de transfert de paquets ne 
correspond pas nScessairement au pont lui-meme. II peut ainsi, en effet, en 
20 reprSsenter un sous-ensemble formS, par exemple, des diffSrents SISments 
permettant de mettre en ceuvre les fonctions de traitement de I'en-tete d'un 
paquet de donnees, de prise en compte d'au moins un identificateur de pont, et 
de transfert de paquets asynchrones. 

Les fonctions de traitement d'en-tete sont mises en ceuvre par 
25 TunitS de calcul CPU 12 et les mSmoires ROM 14 et RAM 16. 

La fonction de transfert d'un paquet asynchrone apres traitement 
de I'en-tete est mise en ceuvre par un bloc logique de controle 34 et des 
composants 30, 32 sur ordre de I'unitS de calcul CPU 12. 

Le pont 66 represents a la figure 3 comporte egalement deux 
30 ensembles de composants appeles aussi blocs 30 et 32 servant 
respectivement d'interfaces avec les bus de communication sSrie 1394, par 
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exemple notes 56 et 58 sur la figure 1. Chaque bloc ou ensemble de 
composants PHY/LINK 1394 est par exemple constitue d'un composant PHY 
TSB21LV03A et d'un composant LINK TSB12LV01A commercialises par la 
societe Texas Instruments et de connecteurs 1394, par exemple 
5 commercialises par la societe Molex, par exemple sous la reference 53462. 

Le pont 66 comporte deux equipements d'interconnexion du pont 
qui forment chacun ce que Ton appelle un "portal" en terminologie anglo- 
saxonne. Chaque "portal" constitue en quelque sorte une portion du pont. 

Sur la figure 3 les elements du pont qui sont references 
10 12,14,16,18,20,22,24,26,28,34,36,38,40,42 et 44 sont communs a chacun des 
equipements d'interconnexion ou "portals" de ce pont et seuls les blocs de 
composants PHYLINK 1394 notes 30 et 32 sont specifiques respectivement a 
chaque equipement d'interconnexion. 

Toutefois, dans certains cas les equipements d'interconnexion ou 
1 5 "portals" d'un pont sont physiquement eloignes (cas d'une liaison radio) et les 
autres elements enonces ci-dessus sont alors propres a chacun des 
equipements d'interconnexion. 

Le bloc logique de controle note 34 peut respectivement 
communiquer avec les blocs de composants 30 et 32 au moyen de bus notes 
20 36 et 38, ainsi qu'avec le composant d'interface PCI 28 au moyen d'un bus 40. 

Des bus 42 et 44 permettent egalement les transferts de donnees 
respectivement entre le composant d'interface PCI 28 et le bloc logique de 
controle 34, ainsi que le bloc de composants PHY/LINK 1394 reference 30, 
d'une part, et, d'autre part, avec le bloc de controle logique 34 et le bloc de 
25 composants PHY/LINK 1 394 reference 32. 

Ce bloc logique de controle 34 permet de transmettre des paquets 
de donnees isochrones ou asynchrones venant du bus de communication serie 
56 par I'intermediaire du bloc de composants PHY/LINK 1394 note 30 qui lui 
est associe et a destination de la memoire RAM 16, sous le controle de la 
30 fonction memoire a acces direct DMA ("Direct Memory Access" en terminologie 
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anglo-saxonne) qui se trouve dans le composant d'interface PCI 28 et qui aura 
ete prealablement initialisee par ['unite de calcul CPU 12. 

Inversement, ce bloc 34 permet egalement de transmettre des 
paquets de donnees isochrones ou asynchrones provenant de la memoire 16 
5 vers I'autre bloc PHY/LINK 1394 note 32, en vue de sa transmission sur le bus 
de communication serie qui lui est associe. Ceci a egalement lieu sous le 
controle de la fonction memoire a acces direct DMA mentionne ci-dessus. 

Le bloc logique de controle 34 permet en outre de declencher une 
interruption PCI par exemple liee a la reception ou a ('emission d'un paquet 
10 asynchrone par I'intermediaire du composant d'interface PCI 28 afin d'informer 
I'unite de calcul CPU 12. De la meme maniere, le bloc logique de controle 34 
est susceptible de generer une interruption PCI pour d'autres types 
d'evenements tels que la reception ou remission de tout autre paquet de 
donnees surun bus 1394. 
15 En outre, le bloc logique 34 permet d'acceder aux differents 

registres des blocs de composants 30 et 32 via le composant d'interface PCI 
28. 

Le bloc logique de controle 34 est un composant de type FPGA 
("Field Programmable Gate Array" en terminologie anglo-saxonne) qui est par 
20 exemple commercialise par la societe Xilinx. 

A chaque bloc de composants 30 et 32 sont associes des 
registres represent.es a la figure 4, utilises pour la mise en ceuvre du precede 
de transfert de paquets de donnees. 

Dans la description qui suit, un registre dont le nom est suffixe par 
25 "_30" ou "_32" appartient aux blocs respectifs 30 et 32 decrits precedemment 
en reference a la figure 3. 

Un registre 91 denomme "routing_label_30", represents sur 8 bits, 
contient un identificateur ou adresse de routage qui identifie les paquets qui 
devront etre transferes du bus 56 vers le bus 58 dans I'exemple du pont 66. 
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Un registre 92 denomme "routing_width_30", represents sur 8 
bits, est associe au registre 91 et indique le nombre de bits significatifs du 
registre 91 . Les registres 91 et 92 sont associes au bloc de composants 30. 

Un registre 93 denomme "routingJabel_32", represente sur 8 bits, 
5 contient un identificateur ou adresse de routage qui identifie les paquets qui 
devront etre transferes du bus 58 vers le bus 56 dans I'exemple du pont 66. 

Un registre 94 denomme "routing_width_32", represente sur 8 
bits, est associe au registre 93 et indique le nombre de bits significatifs du 
registre 93. Les registres 93 et 94 sont associes au bloc de composants 32. 

10 Un registre 97 denomme "max_width", represente par exemple 

sur 32 bits, contient la valeur maximale que peuvent prendre les registres 92 et 
94. Un registre 100 denomme "ERW" ("Elementary Routing Width" en 
terminologie anglo-saxonne) contient la longueur elementaire d'un identificateur 
de routage, c'est a dire la plus petite longueur possible d'identificateur dans le 

15 reseau. Ainsi, sur chaque bus du reseau, la longueur de I'identificateur d'un 
"portal" connecte au bus (contenu dans les registres 92 ou 94 associes aux 
"portals" de chaque pont du reseau) est egale a un multiple entier de ERW. La 
longueur elementaire ERW constitue une caracteristique du reseau. Le registre 
101 denomme "MBNB" ("Maximal Bridge Number" en terminologie anglo- 

20 saxonne) contient le nombre maximal des "portals" actifs sur un bus 
quelconque du reseau. 

Les registres 97, 100 et 101 ne sont pas associes a un 
equipement d'interconnexion ou "portal" en particulier. A un instant donne, ils 
contiennent respectivement la meme valeur dans chaque pont du reseau 

25 considere. 

Dans le mode prefere de realisation, les valeurs des registres 92, 
94 et 97 sont predetermines: la longueur ERW est egale a "2", la valeur de 
max_width est egale a "6" et MBNB est egale a "27" pour chaque pont du 
reseau. On note qu'avec ces valeurs, les longueurs d'identificateur autorisees 
30 sont 2, 4 et 6, permettant ainsi d'adresser respectivement 3, 9 et 27 ponts par 
bus (par exemple, pour une longueur egale a 2, un identificateur peut etre 
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compose des combinaisons de bits "00", "01" ou "10", la combinaison "11" 
etant reservee pour le separateur ou marqueur. 

De maniere generate, MBNB est egal a (2 ERW -1 )™*-widti™ 

Dans des variantes non representees de mise en oeuvre de 
5 I'invention, les valeurs ERW, max_width et MBNB peuvent etre determinees de 
fagon dynamique, en fonction des caracteristiques du reseau. 

Parmi I'ensemble des equipements d'interconnexion ou "portals" 
connectes a un meme bus 1394 la norme P1 394.1 prevoit la determination d'un 
equipement d'interconnexion particulier appele "alpha-portal". 
10 Les moyens de determination de 'Talpha-portal" sont connus et 

notamment decrits dans le chapitre 4.1 du projet de norme P1394.1 version 
0.04, du 7 Fevrier 1999. Ces moyens permettent notamment d'identifier de 
maniere constante et unique les peripheriques d'un meme bus. Par extension 
ces moyens permettent aussi d'affecter de la meme maniere un identificateur 
15 ou label de routage constant et unique a chaque equipement d'interconnexion 
ou "portal" d'un meme bus. 

II convient de noter que chaque equipement (peripherique, 
equipement d'interconnexion...) relie a un bus est repere par un identificateur 
dit physique et par un identificateur dit virtuel. 
20 La correspondance entre I'identificateur physique et I'identificateur 

virtuel d'un equipement est etablie dans une table de correspondance non 
representee sur les figures. La valeur de I'identificateur virtuel d'un equipement 
connecte a un bus reste constante meme si la topologie liee a ce bus est 
modifiee. 

25 Ainsi, vues de I'exterieur du bus, les valeurs des identificateurs 

virtuels ne changent pas malgre une modification de la topologie du bus 
considere. 

Par ailleurs, les equipements d'interconnexion relies a un bus 
possedent egalement I'identificateur de routage mentionne ci-dessus. 
30 Un identificateur de routage ainsi determine, par exemple pour 

I'equipement d'interconnexion du pont 66 qui est relie au bus 56, est stocke 



27 



2805370 



dans le registre 91 et identifie I'equipement d'interconnexion ou "portal" 
contenant le bloc 30 de la figure 3. De meme, un identificateur de routage ainsi 
determine, par exemple pour I'equipement d'interconnexion du pont 66 qui est 
relie au bus 58, est stocke dans le registre 93 et identifie I'equipement 
5 d'interconnexion ou "portal" contenant le bloc 32 de la figure 3. 

Un registre 95 denomme "routing_table_30" sur la figure 4, 
represents sur 960 bits, represents une table de routage associee a 
I'equipement d'interconnexion ou "portal" contenant le bloc 30 et est utilise lors 
du transfert de paquets emis depuis le bus 56, en ce qui concerne le pont 66. 

10 Un registre 96 denomme "routing_table_32", represents sur 960 

bits, represents une table de routage associee a I'equipement d'interconnexion 
ou "portal" contenant le bloc 32 et est utilise lors du transfert de paquets emis 
depuis le bus 58, en ce qui concerne le pont 66. La structure de cette table de 
routage est decrite en detail a la figure 8. 

15 Un registre 98 denomme "portal_numbering_30" sur la figure 4 

comporte, d'une part, au moins une table de correspondance qui est associee a 
I'equipement d'interconnexion ou "portal" contenant le 
bloc 30 et, d'autre part, deux registres notes "CNC_STATE" et 
"ADJ_CNC_STATE". 

20 Un registre 99 denomme "portal_numbering_32" sur la figure 4 

comporte, d'une part, au moins une table de correspondance 1 qui est associee 
a I'equipement d'interconnexion ou "portal" contenant le 
bloc 32 et, d'autre part, deux registres notes "CNC_STATE" et 
"ADJ_CNC_STATE". 

25 Les registres 100, 101, 91, 92, 93, 94, 95, 96, 97, 98 et 99 

representes a la figure 4, sont situes dans la memoire RAM 16 du pont 66 
represents a la figure 3. 

Un paquet asynchrone, emis par un peripherique source situS sur 
un bus different de celui sur lequel est situe le peripherique destinataire, est dit 

30 paquet asynchrone "distant", par opposition a un paquet asynchrone local. 
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En outre, lorsqu'un paquet asynchrone "distant" transite, par 
exemple depuis le peripherique 68 (figure 1) jusqu'au peripherique 69, via ies 
ponts 61, 62, 64, 66 et 67, differents traitements sont appliques par chacun de 
ces ponts en fonction de leur position relative par rapport au peripherique 
5 source et au peripherique destinataire. 

Ainsi, lorsqu'aucun des equipements d'interconnexion ou "portals" 
d'un pont considere n'est connecte ni au bus du peripherique source, ni au bus 
du peripherique destinataire, le pont est dit pont "intermediaire". C'est le cas du 
pont 66 lorsque, par exemple, le peripherique 68 transmet un paquet 
10 asynchrone au peripherique 69. 

La figure 5 illustre de maniere schematique le traitement, 
qu'effectue le pont 66 en tant que pont "intermediaire", sur Ies champs 80 et 81 
d'un paquet asynchrone qu'il transfere depuis le bus 56 vers le bus 58, selon le 
sens indique par la fleche 219. 
15 Le registre 76 est I'equivalent du registre 91 represente a la figure 

4 et a, par exemple, pour valeur "10" en representation binaire sur 2 bits 
significatifs. 

En outre, le registre 77 est I'equivalent du registre 93 represente a 
la figure 4, et a, par exemple, pour valeur "011000" en representation binaire 
20 sur 6 bits significatifs. 

On va maintenant s'interesser, en reference aux figures 5 et 6, au 
transfert d'un paquet asynchrone de donnees note 199 du bus 56 au 
peripherique 69 du bus 59. 

Le paquet asynchrone de donnees 199 transite sur le bus 56 et 
25 est transfere au bus 58, par le pont 66, apres traitement, sous la forme d'un 
paquet 216. Les paquets asynchrones 199 et 216 sont conformes a la structure 
de paquet representee a la figure 2 et ne different I'un de I'autre que par le 
contenu de leurs champs respectifs destination 80 et source 81. 

Le champ 80 du paquet 199 est decompose en plusieurs champs 
30 notes 200, 201, 202 et 203. Le champ 81 du paquet 199 est lui aussi 
decompose en plusieurs champs notes 204, 205, 206, 207 et 208. 
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Les champs 201 et 202, represents respectivement sur 6 et 2 
bits, contiennent les identificateurs de routage des equipements 
d'interconnexion ou "portals" a prendre en compte respectivement par les ponts 
66 et 67 pour transferer le paquet asynchrone jusqu'au peripherique 
5 destinataire 69. 

Les champs 208, 207 et 206, representes chacun sur 2 bits, 
contiennent les identificateurs de routage des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 64, 62 et 61 pour 
transferer un paquet asynchrone en retour jusqu'au peripherique source 68. 
10 Le champ 203, represente sur 6 bits, contient I'information qui 

permet au pont 67 d'identifier le peripherique destinataire 69 du paquet 
asynchrone parmi tous les peripheriques du bus 59. De maniere generale, il 
s'agit du champ 80b "destination_Node_ID" de la figure 2. 

Le champ 204, represente sur 6 bits, contient I'information qui 
15 permet au pont 61 d'identifier le peripherique source 68 du paquet asynchrone 
parmi tous les peripheriques du bus 52. De maniere generale, il s'agit du 
champ 81b "source_Node_ID" de la figure 2. 

Les champs 200 et 205 dont I'ensemble est represente sur 6 bits 
qui sont tous positionnes a "1", contiennent un marqueur delimitant les champs 
20 202 et 201 , d'une part, des champs 208, 207 et 206, d'autre part. 

Les champs 201 et 202 forment ce que Ton appelle un premier 
champ d'informations et identifient le chemin qui est a parcourir par le paquet 
de donnees 199. 

Les champs 206, 207 et 208 forment ce que Ton appelle un 
25 deuxieme champ d'informations et identifient le chemin deja parcouru par le 
paquet de donnees 199. 

Les champs 200 et 205 forment ce que Ton appelle un troisieme 
champ d'informations ou marqueur. 

Dans le cas du paquet 216 issu du pont 66, le champ 80 
30 comprend les champs 209, 210, 211 et 203 et le champ 81 comprend les 
champs 212, 213, 214 et 204. 
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Le champ 211, represents sur 6 bits, contient I'identificateur de 
routage a prendre en compte par le pont 67 pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 69. II correspond au champ 201 
du paquet 199. 

5 Les champs 214, 213 et 212, represents respectivement sur 6, 2 

et 2 bits, ainsi que le champ 209, represente sur 2 bits, contiennent les 
identificateurs de routage a prendre en compte respectivement par les ponts 
66, 64, 62 et 61, pour transferer le paquet asynchrone, en retour, jusqu'au 
peripherique source 68. Les champs 212 et 213 correspondent respectivement 

10 aux champs 207 et 208 du paquet 199. Le champ 209 correspond au champ 
206 du paquet 199. 

Le champ 210, represente sur 2 bits, qui sont tous positionnes a 
"1", contient le marqueur delimitant le champ 211, d'une part, des champs 209 
a 214, d'autre part. II correspond aux champs 205 et 200 du paquet 199. 

15 A la reception du paquet 199, le pont 66 lit et analyse la valeur du 

champ 202 qu'il compare avec le contenu du registre 76. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 199 va etre transfere du bus 56 au bus 58 sous la forme du paquet 216. 

On notera qu'entre le paquet 199 et le paquet 216, le pont 66 a, 

20 d'une part, supprime du premier champ d'informations une premiere information 
constitute par les bits "10" appartenant au champ 202 et, d'autre part, ajoute 
au deuxieme champ d'informations une deuxieme information constitute par 
les bits "011000" du registre 77 d'identification de I'equipement d'interconnexion 
ou "portal" considere. 

25 Sur la figure 5, il convient de noter que, d'une part, la suppression 

d'une premiere information (champ 202) du premier champ d'informations 
reduit la longueur de ce dernier et, d'autre part, I'ajout d'une deuxieme 
information (champ 214) dans le deuxieme champ d'informations augmente la 
longueur de ce dernier. 

30 Cette deuxieme information est representee par le champ 214. 
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Le precede de transfert de paquets precede egalement, apres la 
suppression de la premiere information et avant I'ajout de la deuxieme 
information, au decalage des premier, deuxieme et troisieme champs 
d'informations a I'interieur des sous-champs 80a et 81a des champs 80 et 81. 

Lorsque Tun des equipements d'interconnexion ou "portals" d'un 
pont est connecte au bus du peripherique destinataire, le pont est dit pont 
"destination". C'est le cas par exemple du pont 67 de la figure 1 lorsque le 
peripherique 69 regoit un paquet asynchrone distant en provenance du 
peripherique 68. 

La figure 6 illustre de maniere schematique le traitement, 
qu'effectue le pont 67 en tant que pont "destination", sur les champs 80 et 81 
du paquet asynchrone 216 qu'il transfere depuis le bus 58 vers le bus 59, selon 
le sens indique par la fleche 229. 

Le registre 78 illustre, pour le pont 67, le registre 91 represente a 
la figure 4 et dont la valeur, sur 6 bits significatifs, est "010110" en 
representation binaire. Par ailleurs, le registre 79 illustre, pour le pont 67, un 
registre 93 represente figure 4 et dont la valeur, sur 4 bits significatifs, est 
"0000" en representation binaire. 

Le paquet asynchrone 216 qui transite sur le bus 58, est transmis 
sur le bus 59, par le pont 67 apres traitement, sous la forme d'un paquet 226. 
Les paquets asynchrones 216 et 226 sont conformes a la structure de paquet 
representee a la figure 2 et ne different I'un de I'autre que par le contenu de 
leurs champs respectifs 80 et 81 . 

Dans le cas du paquet 226, le champ 80 est decompose en 
plusieurs champs 220 (sous champ 80a) et 221 (sous champ 80b) et le champ 
81 est lui aussi decompose en plusieurs champs 223, 224 (sous champ 81a) et 
204 (sous champ 81b). 

Le champ 220, represente sur 10 bits qui sont tous positionnes a 
"1", est representatif d'un paquet asynchrone destine au bus local et 
susceptible d'etre recu par I'un des peripheriques du bus 59. 
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Le champ denomme "offset" et note 223 est ajoute par le pont 67 
alors que le champ 224 contient I'identificateur de routage ou adresse de 
I'equipement d'interconnexion ou "portal" du pont 67 associe au bus 59 et 
stocke dans le registre 79. 
5 A la reception du paquet 216, le pont 67 lit et analyse la valeur du 

champ 211 qu'il compare avec le contenu du registre 78. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 216 va etre transfere du bus 58 au bus 59 sous la forme du paquet 226. 

Lors du transfert du paquet 216 a travers le pont 67, ce dernier a 
10 supprime d'un premier champ d'informations qui est forme du champ 21 1, une 
premiere information constitute par les bits "0101 10" du champ 21 1 lui-meme. 

Ce premier champ d'informations identifie le chemin restant a 
parcourir au paquet 216 pour parvenir a destination. 

Le pont 67 a ensuite sauvegarde dans la table de routage 
15 associee a I'equipement d'interconnexion ou "portal" comprenant le registre 79 
un deuxieme champ d'informations qui est forme de I'ensemble des champs 
209, 212, 213 et 214. 

Ce deuxieme champ d'informations identifie le chemin parcouru 
par le paquet 216 et ce sera le chemin dit de "retour" qui lui permettra, 
20 eventuellement, d'etre renvoye au peripherique source. 

Le pont 67 a ensuite renseigne ce deuxieme champ 
d'informations alors forme par le champ 224, par une deuxieme information 
constitute par les bits "0000" du registre 79 d'identification de I'equipement 
d'interconnexion ou "portal" considered 
25 Le troisieme champ d'informations correspond au marqueur note 

210 et precedemment evoque. 

Le procede de transfert de paquets precede egalement, apres la 
suppression de la premiere information et avant I'ajout de la deuxieme 
information, a la sauvegarde du deuxieme champ d'informations, au stockage 
30 de I'index de cette sauvegarde dans le champ 223 et a la mise a "1" de tous les 
bits du champ 220. 
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Le champ 203, represents sur 6 bits, permet au pont "destination" 
67, d'identifier le peripherique destinataire 69 du paquet asynchrone parmi tous 
les peripheriques du bus 59. Le champ 203 du paquet 216 a ete remplace, lors 
du transfert dans le pont 67, par le champ 221 dans le paquet 226. Le champ 
221 identifie, par exemple, le peripherique 69 parmi tous les peripheriques du 
bus 59, afin que le paquet 226 soit regu par le peripherique 69. Le champ 203 
contient I'identificateur virtuel du p6ripherique 69 alors que le champ 221 
contient I'identificateur physique du peripherique 69 

Le champ 204, represents sur 6 bits, contient I'information qui 
permet au pont 61 d'identifier le peripherique source 68 emetteur du paquet 
asynchrone parmi tous les peripheriques du bus 52. Le champ 204 est 
representatif de I'identificateur virtuel du peripherique 68. 

Lorsque Tun des equipements d'interconnexion ou "portals" d'un 
pont est connecte au bus du peripherique source le pont est dit pont "source". 
C'est le cas par exemple du pont 67 de la figure 1 lorsque le peripherique 69 
transmet un paquet asynchrone "distant" a destination du peripherique 68, par 
exemple en reponse au paquet 226. 

La figure 7 illustre de maniere schematique les modifications 
effectuees par le pont 67 en tant que pont "source", sur les champs 80 et 81 
d'un paquet asynchrone qu'il transfere depuis le bus 59 vers le bus 58, selon le 
sens indique par la fleche 230. 

Le paquet asynchrone 231 emis sur le bus 59 par le peripherique 
69 est transfere sur le bus 58, par le pont 67, apres traitement, sous la forme 
d'un paquet 240. Les paquets asynchrones 231 et 240 sont conformes a la 
structure de paquet representee a la figure 2 et ne different I'un de I'autre que 
par le contenu de leurs champs respectifs 80 et 81 . 

Dans le cas du paquet 231, le champ destination 80 est 
decompose en plusieurs champs 232, 233 et 234 et le champ source 81 est 
egaiement decompose en plusieurs champs 235 et 236. 

Le champ denomme "offset" et note 232 est utilise par le pont 67 
pour retrouver ('ensemble des identificateurs de routage a prendre en compte, 
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respectivement par les ponts 66, 64, 62 et 61, pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 68. Le champ 233 contient 
I'identificateur de routage du pont 67 associe au bus 59 et stocke dans le 
registre 79. 

Le champ 236, represente sur 10 bits, qui sont tous positionnes a 
"1", est representatif d'un paquet asynchrone emis par le bus local. 

Dans le cas du paquet 240, le champ destination 80 est 
decompose en plusieurs champs 241, 242, 243 et 234 et le champ source 81 
est egalement decompose en plusieurs champs 246, 247, 248 et 249. 

Les champs 243, 242 et 241, representes respectivement sur 6, 2 
et 2 bits, ainsi que le champ 246, represente sur 2 bits, contiennent les 
identificateurs de routage ou adresses des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 66, 64, 62 et 61, 
pour transferer le paquet asynchrone jusqu'au peripherique destination 68. 

Le champ 248, represente sur 6 bits, contient I'identificateur de 
routage a prendre en compte par le pont 67 pour transferer en retour le paquet 
asynchrone jusqu'au peripherique source 69. 

Le champ 247, represente sur 2 bits et dont tous les bits sont 
positionnes a "1", contient un marqueur delimitant les champs 241 a 243, 234 
et 246, d'une part, du champ 248, d'autre part. 

A la reception du paquet 231, le pont 67 lit et analyse la valeurdu 
champ 233 qu'il compare avec le contenu du registre 79. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 231 va etre transfere du bus 59 au bus 58 sous la forme du paquet 240. 

On notera que dans le paquet 240, les identificateurs de routage 
241, 242, 243 et 246 representatifs du chemin a parcourir jusqu'au 
peripherique destination 68 et le champ 248 representatif du chemin parcouru 
depuis le peripherique source 69 ont ete initialises par le pont 67 dans le 
paquet 240. 

Pour cela, le pont utilise la valeur stockee dans le champ "offset" 
232 du paquet 231 qu'il aura prealablement communique au peripherique 
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source 69, par exemple, par I'intermediaire d'un paquet asynchrone 
precedemment recu. Ainsi, si, par exemple, le paquet 231 de la figure 7 
constitue la reponse du peripherique 69 au paquet regu 226 sur la figure 6, on 
notera que la valeur des champs 223 et 224 du paquet de donnees 226 est 
5 identique respectivement a la valeur des champs 232 et 233 du paquet 231 de 
la figure 7. 

On notera aussi que dans ce cas, la valeur des champs 209, 210, 
211 du paquet 216 de la figure 6 est respectivement egale a la valeur des 
champs 246, 247 et 248 du paquet 240 de la figure 7. De meme, la valeur des 
10 champs 212, 213 et 214 du paquet 216 est egale respectivement a la valeur 
des champs 241 , 242 et 243 du paquet 240. 

Lors du transfert du paquet 231 a travers le pont 67, ce dernier a 
insere le premier champ d'informations qui est forme des champs 243, 242, 
241 et 246. Ce premier champ d'informations identifie le chemin restant a 
1 5 parcourir au paquet de donnees 231 pour parvenir a destination. 

Le pont 67 a ensuite ajoute dans un deuxieme champ 
d'informations, vide au prealable, une deuxieme information constitute par les 
bits "010110" du registre 78 d'identification d'un equipement d'interconnexion 
ou "portal" considere. Cette deuxieme information est representee par le champ 
20 248. 

Ce deuxieme champ d'informations identifie le chemin parcouru 
par le paquet 231 depuis le peripherique 69 et ce sera le chemin d'informations 
dit de "retour" qui lui permettra, eventuellement, d'etre renvoye au peripherique 
source. 

25 Le troisieme champ d'informations correspond a une partie du 

champ 236 qui est transformee dans le paquet 240 en un champ 247 appele 
"marqueur". 

Le procede de transfert de paquets procede egalement, apres la 
suppression de la premiere information et avant I'ajout de la deuxieme 
30 information, a la lecture de la table de routage associee a I'equipement 
d'interconnexion du registre 79. 
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Le contenu du champ 235, code sur 6 bits, est representatif de 
I'identificateur physique du peripherique 69 parmi tous les peripheriques du bus 
59. Le champ 235 du paquet 231 a ete remplace par le champ 249 dans le 
paquet 240. La valeur du champ 249 , est quant a elle representative de 
I'identificateur virtuel du peripherique 69 parmi tous les peripheriques du bus 
59. 

Le champ 234, code sur 6 bits, est representatif de I'identificateur 
virtuel du peripherique destinataire 68 du paquet asynchrone parmi tous les 
peripheriques du bus 52. 

On notera que la valeur du champ 234 est 6gale a la valeur du 
champ 204 des figures 5 et 6. De meme, la valeur du champ 249 est egale a la 
valeur du champ 203 des figures 5 et 6 et la valeur du champ 235 est egale a 
la valeur du champ 221 de la figure 6. 

Ainsi, on comprend que, lors du transfer! d'un paquet par un pont 
intermediaire, I'identificateur de routage de I'equipement d'interconnexion ou 
"portal" par lequel arrive le paquet est supprime du premier champ 
d'informations car il est devenu inutile et I'identificateur de routage de 
I'equipement d'interconnexion ou "portal" par lequel le paquet quitte le pont est 
ajoute dans un deuxieme champ d'informations afin de reconstruire le chemin 
parcouru par le paquet. 

Lorsque les deux identificateurs n'ont pas la meme longueur, la 
longueur du marqueur est modifiee afin que la longueur totale des premier, 
deuxieme et troisieme champs d'informations (figure 5) reste inchangee. 

On notera que la longueur du marqueur est ainsi ajustee au 
niveau du pont traverse par le paquet. 

En outre, lorsqu'un identificateur est affecte a un equipement 
d'interconnexion d'un pont, la suite de bits pour I'identificateur est choisie parmi 
un ensemble de valeurs ne contenant pas la suite predeterminee de bits 
correspondant au marqueur. Le traitement de I'en-tete s'en trouve simplifie 
puisque I'on s'assure ainsi de ne pas retrouver la suite de bits correspondant 
au marqueur a I'interieur d'autres identificateurs. 



37 



2805370 



En reduisant la longueur du premier champ et en augmentant la 
longueur du deuxieme champ au fur et a mesure du transfert du paquet par 
differents ponts du reseau on peut done augmenter la distance maximale 
parcourue par un paquet par rapport a I'art anterieur dans lequel la longueur de 
5 chaque champ destination et source reste fixe au cours du temps. 

II convient de remarquer que le troisieme champ ou marqueur a 
une longueur au moins egale a la longueur elementaire (ERW) d'un 
identificateur de routage d'un equipement d'interconnexion ou "portal", 
contenue dans le registre ERW, reference 100 sur la figure 4. 
10 Comme precedemment mentionne, le marqueur comporte une 

suite predeterminee de bits qui peut etre, par exemple, une suite consecutive 
de bits ayant tous un meme etat "0" ou"1". 

L'utilisation et la gestion du champ "offset" par les ponts source et 
destination sont plus particulierement decrites en reference aux figures 8, 9 et 
15 10. 

La figure 8 est une vue schematique detaillee d'une table de 
routage illustree par chaque registre 95, 96 de la figure 4 et qui est stockee 
dans la memoire RAM de chaque equipement d'interconnexion ou "portal" d'un 
pont source ou destination. Cette table a pour objectif d'associer a un index 
20 ("offset" en terminologie anglo-saxonne) unique sur le bus local, un chemin 
permettant d'atteindre un peripherique distant et vice-versa. 

Cette table est composee d'un ensemble d'enregistrements 
elementaires 250 a 259, chaque enregistrement elementaire etant associe a un 
index dans la table. Les enregistrements 250, 251, 252, 253, 254, 255, 256, 
25 257, 258 et 259 sont respectivement associes aux index "0", "1", "2", "3", "4", 
"5", "6", "7", "8", "9". 

La structure d'un enregistrement elementaire est par exemple 
constitute des champs suivants. 

Le champ 270 "path_descriptor" correspond a un "descripteur de 
30 chemin", represents sur 16 bits et qui contient ('information de routage 
permettant d'atteindre le peripherique destinataire distant. 
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Le champ 271 "activ" (raccourci de "activity", terminologie anglo- 
saxonne de "activite") represente sur 16 bits, contient I'information concernant 
la gestion au niveau du bus local dudit descripteur de chemin. 

Ce champ est notamment utilise pour connaTtre, a un moment 
5 donne, combien de transactions de type "Requite" et "en attente de Reponse" 
sont en cours de traitement. 

Ce champ peut egalement etre utilise afin de connaTtre depuis 
combien de temps I'enregistrement elementaire n'a pas ete consulte. 

Pour ce faire, un compteur est increments suivant une periode 
10 predefinie par I'equipement d'interconnexion ou "portal" et est remis a zero a 
chaque utilisation de I'information "descripteur de chemin" ou de I'index. Ce 
champ permet ainsi d'optimiser la gestion de la memoire de la table de routage. 

II convient de noter que les index ("offsets") des enregistrements 
elementaires, non en cours d'utilisation et/ou n'ayant pas ete utilise depuis un 
15 certain temps, sont de preference reutilises en premier. 

Le champ 272 "local_bus_bit_map", represente sur 64 bits, 
permet de decrire quels sont les peripheriques sur le bus local qui utilisent 
effectivement ce descripteur de chemin. Chacun des 64 bits, indexes de 0 a 63, 
correspond au peripherique dont I'identificateur physique a pour valeur I'index 
20 en question. 

Comme precedemment mentionne, ce champ permet d'optimiser 
la gestion de la memoire de la table, en evitant de reutiliser un index qui est 
utilise, meme peu souvent, par un nombre eleve de peripheriques. 

Ce champ presente surtout I'avantage de pouvoir determiner, 
25 dans le cas ou un index a ete attribue a un autre enregistrement elementaire, si 
I'index est toujours d'actualite pour un peripherique donne sur le bus local. 

La figure 8 decrit par exemple une table de routage pouvant 
contenir jusqu'a dix enregistrements elementaires qui sont alors indexes de 0 a 
9. Chaque enregistrement elementaire contient trois mots de 32 bits. La taille 
30 maximale des enregistrements elementaires etant atteinte, une gestion de 
ceux-ci est necessaire afin d'en liberer avant de pouvoir en ajouter. 
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On notera que la longueur des champs 270, 271 et 272 est 
indicative et peut etre reduite ou augmentee suivant les capacites du reseau. 

Ainsi, par exemple, si I'on autorise un maximum de 32 
peripheriques par bus, ceci incluant les ponts, la longueur du champ 272 
"local_bus_bit_map" peut etre reduite a 32 bits et le nombre total d'index peut 
etre augmente jusqu'a 15 pour une meme occupation de la memoire. 

Cette gestion peut obeir a differentes politiques comme par 
exemple celle selon laquelle les enregistrements elementaires non en cours 
d'utilisation et n'ayant pas ete utilise depuis une certaine duree sont liberes. 

De meme, le nombre de peripheriques qui ont utilise et qui sont 
encore susceptibles d'utiliser un enregistrement elementaire donne peut 
avantageusement etre pris en compte. 

La figure 9 est une vue schematique de I'algorithme d'un precede 
de recuperation d'un descripteur de chemin a partir d'un index dans la table de 
routage decrite en figure 8. 

Ce procede est, par exemple, mis en ceuvre dans le pont 67 de la 
figure 7 lors du transfert du paquet 231 du bus 59 vers le bus 58. 

Ces instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM du pont considered 

Au cours d'une etape 301, le procede prevoit de recevoir une 
requete de recuperation d'un descripteur de chemin a partir d'un index donne. 

Au cours de I'etape 302, il est verifie que I'index en question se 
refere bien a un enregistrement elementaire dans la table de routage. Dans le 
cas positif, le traitement se poursuit par I'etape 303. Dans le cas negatif, le 
procede prevoit de retoumer une information signifiant qu'aucun descripteur de 
chemin n'est valide pour ledit index (etape 305). 

Au cours de I'etape 303, le procede comporte une etape de 
verification selon laquelle I'enregistrement elementaire correspond bien a 
I'index presente par le peripherique a I'origine de la requete. II se peut en effet 
que I'enregistrement elementaire correspondant audit index ait ete supprime de 
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la table, puis que cette valeur d'index ait ete reutilisee pour decrire un autre 
enregistrement elementaire pour un autre peripherique. 

Pour ce faire, un ensemble de 64 bits (indexes de 0 a 63) est 
utilise pour dresser une carte des peripheriques utiiisant I'enregistrement 
5 elementaire en question. 

Chaque bit permet de savoir si, pour le peripherique dont 
I'identificateur physique a pour valeur I'index parmi les 64 bits, I'enregistrement 
elementaire est valide ou non. 

Dans le cas ou I'information est dite non valide, le precede prevoit 
10 de retourner une information signifiant qu'aucun descripteur de chemin n'est 
valide pour ledit index (etape 305). 

Dans le cas ou information est valide, I'etape 303 est suivie de 

I'etape 304. 

Au cours de I'etape 304, le precede effectue une lecture du 
15 descripteur de chemin, met a jour les informations de gestion relatives a 
I'enregistrement elementaire, et retourne finalement le descripteur de chemin 
pour ledit index. 

Parmi les informations de gestion relatives a I'enregistrement 
elementaire, on peut notamment citer les deux actions suivantes : 
20 - Premierement, quand une demande de recuperation d'un 

descripteur de chemin a partir d'un index est issue d'une transaction de type 
"Requete", un compteur indiquant I'usage de cet enregistrement elementaire 
est incremente si une transaction de type "Reponse" est attendue. Ce compteur 
sera decrements lors d'une prochaine demande de recuperation d'un index a 
25 partir d'un descripteur de chemin issue d'une transaction de type "Reponse". 

- Deuxiemement, a chaque utilisation de I'enregistrement 
elementaire, le compteur indiquant la duree ecoulee depuis la derniere 
utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre incremente sur un 
30 evenement temporel genere avec une periode predefinie. 
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Apres avoir retourne le descripteur de chemin ou I'absence de 
descripteur de chemin pour ledit index, le procede prevoit de revenir a I'etape 
301 pour traiter toute nouvelie demande de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage. 
5 La figure 10 est une vue schematique de I'algorithme d'un 

procede de recuperation d'un index a partir d'un descripteur de chemin dans la 
table de routage decrite en figure 8. 

Ce procede est par exemple mis en ceuvre dans le pont 67 de la 
figure 6 lors du transfert du paquet 216 du bus 58 vers le bus 59. 
10 Les instructions ou etapes d'un tel procede sont stockees dans la 

memoire ROM du pont considere. 

Au cours d'une etape 311, le procede prevoit de recevoir une 
requete de recuperation d'un index a partir d'un descripteur de chemin donne. 

Au cours de I'etape suivante 312, le procede prevoit de verifier 
1 5 que le descripteur de chemin en question est present dans la table de routage. 

Dans le cas positif, I'etape 312 est suivie de I'etape 315, au cours 
de laquelle on met a jour, le cas echeant, les informations de gestion relatives a 
I'enregistrement elementaire, et I'index correspondant audit descripteur de 
chemin est retourne. 

20 Concernant les informations de gestion relatives a 

I'enregistrement elementaire, on peut notamment citer les deux actions 
suivantes : 

- Premierement, quand une demande de recuperation d'un 
descripteur de chemin a partir d'un index est issue d'une transaction de type 

25 "Reponse", le compteur indiquant I'usage de cet enregistrement elementaire 
est decrements. 

- Deuxiemement, le compteur indiquant la duree ecoulee depuis la 
derniere utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre increments sur un 
30 evenement temporel genere avec une periode predefinie. 
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Dans le cas negatif, le procede comporte une etape 313 au cours 
de laquelle il est verifie si au moins un index (et done un enregistrement 
elementaire) est libre dans la table de routage. 

Dans le cas positif, au cours d'une etape 314, un index est affecte 
et utilise pour stocker le descripteur de chemin d'informations. 

Un bit parmi I'ensemble des 64 bits (indexes de 0 a 63) qui 
correspond a I'identificateur physique du peripherique a I'origine de la 
demande, est positionne afin de valider cet enregistrement elementaire pour le 
peripherique en question. 

Si I'index n'est pas libre, le procede procede a la liberation d'un ou 
plusieurs index (et done d'enregistrement(s) elementaire(s)) dans la table de 
routage au cours d'une etape 316. 

L'etape suivante 317 consiste a verifier si I'etape de liberation a 
pu se faire avec succes. Dans le cas positif, I'etape 314 precedemment decrite 
est a nouveau effectuee. Dans le cas negatif, au cours d'une etape 318, le 
procede prevoit de retourner une information indiquant I'absence d'index (et 
done d'enregistrement elementaire) pour ledit descripteur de chemin. Ensuite, 
I'etape 311 est executee de nouveau. 

La figure 11 represente un algorithme sur lequel est base un 
procede de routage des paquets asynchrones au niveau d'un pont. 

Les instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM de chaque pont. 

Cet algorithme concerne la prise de decision de routage desdits 
paquets ainsi que la transformation de leurs en-tetes, en fonction du resultat de 
I'analyse du contenu des en-tetes des paquets regus. 

Dans la suite de la description, des variables temporaires 
stockees dans la memoire RAM du pont considere (D_BuslD, S_BuslD, in_RI, 
out_RI, path_register) ont ete introduites pour faciliter la comprehension de 
I'algorithme sur lequel est base le procede. 

Le procede debute par une etape notee 400 sur la figure 11 
consistant en I'attente de la reception d'un paquet asynchrone. Lorsqu'un tel 
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paquet a ete recu et stocke en memoire, on passe a I'etape 401 d'analyse de 
I'identificateur du bus de destination D_BuslD compris dans I'en-tete dudit 
paquet. 

Dans la suite de la description, D_BuslD represente 1'information 
du champ 80a "destination_Bus_ID" de la figure 2, de meme S_BuslD 
represente rinformation du champ 81a "source_BusJD" de cette meme figure. 

Si ledit identificateur est egal a 3FF 16 , il s'agit alors soit d'un 
paquet emis sur le bus local et destine a ce bus local, soit d'un paquet distant 
arrive sur son bus de destination (comme decrit en figure 6). Dans ce cas 
d'egalite, I'etape 401 est suivie par I'etape 402 consistant, puisque ce paquet 
est destine audit bus local, a rejeter le paquet sans autre traitement. L'etape 
402 est suivie par I'etape 400 d'attente d'un nouveau paquet asynchrone. 

Lorsqu'au cours de I'etape 401 on trouve un identificateur du bus 
de destination different de 3FF 16 , cela signifie que le paquet est au niveau d'un 
pont intermediaire et les etapes 403 et 404 sont alors executees. 

II convient de noter que, dans la suite de la description, selon le 
cas de figure envisage, I'information ou identificateur (ou label) de routage du 
descripteur de chemin de destination est lu dans les bits de poids faibles du 
champ D_BuslD et I'information ou identificateur (ou label) de routage du 
descripteur de chemin parcouru est ecrit dans les bits de poids faibles du 
champ S_BuslD, les bits etant decales d'un champ a I'autre de facon 
appropriee. 

Par exemple, on procede a un decalage a droite du champ 
D_BuslD et a un decalage a gauche du champ S_BuslD, chaque bit issu du 
decalage a gauche du bit de poids fort du champ S_BusiD etant insere, apres 
decalage a droite des bits du champ D_BuslD , a la place du bit de poids fort 
du champ D_BuslD. 

D'autres variantes consistant a combiner lecture/ecriture des 
informations de routage des descripteurs de chemin sur les poids forts/faibles 
des champs D_BuslD et S_BuslD avec les decalages appropries ne sont pas 
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decrites dans la presente description, mais peuvent etre envisagees par 
I'homme du metier. 

De retour a I'algorithme de la figure 1 1 , I'etape 403 consiste a 
determiner I'identificateur ou label de routage du descripteur de chemin de 
5 destination in_RI. 

Pour ce faire I'identificateur ou label de routage est extrait du 
champ D_BuslD d'une longueur ou taille (en bits) egale au contenu du registre 
"routing_width_30" 92 (figure 4) associe a I'equipement d'interconnexion ou 
"portal" d'entree ("inbound portal" en terminologie anglo-saxonne). 
10 Dans I'exemple de la figure 5 , le champ D_BuslD vaut 

"11 0101 1010 2 ", la valeur routing_width_30 est egale a 4 et I'identificateur ou 
label de routage in_RI est egal a 001 0 2 . 

Une fois la valeur de I'identificateur ou label de routage in_RI du 
paquet connue, I'etape 404 permet de la comparer au contenu du registre 
15 "routing_label_30" 91 qui constitue I'unique identificateur ou label de routage 
affecte pour le bus considere a I'equipement d'interconnexion ou "portal" sur 
lequel le paquet en question a ete recu. 

Si les deux valeurs sont differentes, alors I'etape 405 est 
executee. Cette etape consiste a rejeter le paquet puis a passer a I'etape 400 
20 decrite ci-dessus. 

Dans le cas contraire, c'est-a-dire lorsque les valeurs in_RI et 
routing_label_30 sont egales, I'etape 404 est suivie du test 406 afin d'analyser 
I'identificateur du bus source SJ3uslD compris dans I'en-tete du paquet traite. 

Si I'identificateur est egal a 3FF 16 cela signifie que le paquet est 
25 situe au niveau d'un pont source, alors le paquet est dit "distant" (destinataire 
sur un bus distant) et est regu de son bus source (comme par exemple le 
paquet reference 231 en figure 7). L'en-tete de ce paquet sera alors traite 
suivant les etapes 410, 411, 412, 413 ou 414 et 415 decrites de facon plus en 
detail ci-dessous. 

30 Dans le cas contraire, le paquet "distant" traite transite sur un bus 

intermediate entre son bus source et son bus de destination (comme par 
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exemple le paquet reference 216 en figure 5). Le traitement de I'en-tete du 
paquet suit alors les etapes 420 et 421 egalement decrites ci-dessous. 

Pendant I'etape 410, on extrait du champ D_BuslD du paquet un 
index ("offset" en terminologie anglo-saxonne) de routage (precedemment 
defini lors de la description des figures 6 et 7) en tenant compte de la valeur 
routing_width_30 mentionnee ci-dessus lors de I'explication de I'etape 403. Cet 
index ("offset") est constitue des (10 - routing_width_30) bits de poids forts du 
champ D_BuslD, 10 etant la largeurdudit champ D_BuslD. 

Par exemple, dans le cas ou le champ D_BuslD vaut 
"0001 10 0000 2 " et la valeur routing_width_30 est egale a 4, I'index sera egal a 
0001 10 2 . 

Ensuite, pendant I'etape 411, I'index ("offset") est converti en 
descripteur de chemin selon le precede de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage, tel que decrit ci-dessus 
(figure 9, etapes 301 a 305). 

Un test 412 consiste alors a verifier si un tel descripteur de 
chemin a ete trouve au cours de I'execution du precede. 

Dans le cas negatif, on execute I'etape 413 consistent a rejeter le 

paquet traite. 

Dans des variantes de mise en oeuvre de ce precede, des 
methodes de traitement d'erreur plus sophistiquees (dont le detail n'est pas 
reproduit sur les figures) peuvent etre envisagees au cours de I'etape 413. 

De telles methodes consistent, par exemple, a envoyer un 
acquittement negatif au peripherique dont est issu le paquet pour lequel le 
descripteur de chemin est obsolete, permettant a celui-ci d'ajuster sa table de 
routage sans attendre I'expiration d'une certaine duree ("time-out" en 
terminologie anglo-saxonne). 

L'etape 413 est suivie par I'etape 400 d'attente d'un nouveau 
paquet a traiter deja decrite ci-dessus. 

Dans le cas positif du test 412, le descripteur du chemin, retourne 
par I'etape 411, est stocke dans le registre "path_register" au cours de I'etape 
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414. Le registre "path_register" est utilise pour la gestion des descripteurs de 
chemin (chemin destination et chemin parcouru) et est avantageusement 
compose de deux sous-champs, chacun de ces sous-champs correspondant 
aux informations respectivement contenues dans les champs D_BuslD et 
S_BuslD. 

Ensuite, au cours de l'etape 415, le precede effectue, sur le 
registre "path_register", le remplacement de I'identificateur physique du 
peripherique present dans le champ de I'adresse source 235 du paquet de la 
figure 7 par I'identificateur virtuel correspondant, ceci en utilisant une table de 
correspondance appropriee etablie lors de chaque reinitialisation ("bus reset" 
en terminologie anglo-saxonne) du bus source 52 de la figure 1. Cette table 
etablissant la correspondance entre identificateurs physiques et virtuels des 
differents equipements (peripheriques, ponts, ...) connectes a un bus est bien 
connue de I'homme du metier. 

L'etape 415 est alors suivie par une etape 430 dont la description 
est faite plus loin. 

De retour a l'etape 406, si I'identificateur est different de 3FF 16 , 
alors cette etape est suivie d'une etape 420 de traitement d'un paquet regu a 
partir d'un bus intermediate. 

L'etape 420 consiste a charger (memorisation) le registre 
"path_register" a partir des identificateurs de bus D_BuslD et S_BuslD extraits 
respectivement des champs "sourceJD" 81 et "destinationJD" 80 de I'en-tete 
(figure 2) du paquet traite. 

On rappelle ici que chacun des deux identificateurs du bus est 
constitue des 10 bits de poids fort du champ d'adresse correspondant (sous 
champ 80a ou 81a), tandis que les 6 bits restants desdits champs d'adresse 
represented I'identificateur (soit physique, soit virtuel) du peripherique adresse 
sur le bus donne. 

L'operation de chargement tient compte du mode de gestion des 
champs D_BuslD et S_BuslD mentionne precedemment comme, par exemple, 
le decalage a droite du champ D_BuslD et le decalage a gauche du champ 
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S_BuslD, et ou chaque bit issu du decalage a gauche du bit de poids fort du 
champ S_Bus!D est insere, apres decalage a droite des bits du champ 
D_BuslD, a la place du bit de poids fort du champ D_BuslD. 

Ensuite, au cours de I'etape 421, le contenu du registre 
"path_register" est transforme de la facon indiquee ci-apres (pour une meilleure 
comprehension de cette etape, le lecteur est prie de se referer a la figure 5). 

On repere tout d'abord une sequence de longueur maximale 
comportant au moins un nombre ERW de bits consecutifs a "1" dont le debut 
est aligne sur une position etant un multiple entier de ERW (ERW etant la 
valeur du registre 100 de la figure 4), cette sequence constituant un marqueur 
ou separateur entre le champ identifiant le chemin de destination et le champ 
identifiant le chemin parcouru. 

Plus particulierement, le traitement de I'en-tete du paquet de 
donnees comporte une etape d'identification du marqueur dans le paquet de 
donnees au cours de laquelle on precede a une lecture, parmi les bits des 
champs 80a et 81a, des bits groupes suivant une longueur egale a un multiple 
entier de la caracteristique ERW. 

On lit done, par exemple, les bits 2 par 2 si ERW=2. 

^identification du marqueur dans I'en-tete du paquet de donnees 
est ainsi simplifiee et plus rapide lors du traitement de cet en-tete au niveau 
d'un pont. 

Nous rappelons ici que dans le mode de realisation decrit, la 
valeur ERW est egale a 2. Dans I'exemple du paquet 199 illustre a la figure 5, 
la sequence comporte 6 bits a "1" et commence au bit 8, la sequence 
"010110 10 2 " decrit le chemin de destination, et la sequence "10 01 00 2 " decrit 
le chemin parcouru. 

II convient de noter ici qu'en separant les trois champs cites de la 
maniere precedemment decrite, d'eventuels bits adjacents au marqueur 
appartenant au champ du chemin parcouru et/ou au champ du chemin de 
destination ne seront jamais attribues au marqueur de facon erronee, meme 
dans le cas ou lesdits bits sont egaux a "1". 
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On effectue ensuite un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du champ descripteur du chemin de 
destination (identificateur du chemin a parcourir) d'un nombre de bits qui est 
egal a la valeur routing_width_30. 

Les bits non significatifs, suite au decalage, se trouvent 
positionnes a "1" et les bits du marqueur ne sont pas modifies. Le registre 
"routing_width_30" 92 indique la longueur en bits de I'identificateur ou label de 
routage sur le bus d'entree du paquet traite. 

Ainsi, dans I'exemple de la figure 5, les bits du champ 202 ont 
disparu, les bits du champ 201 ont ete decale d'un nombre de bits egal a la 
valeur routing_width_30 (a droite dans le champ "destination_Bus_ID" 80a de 
la figure 2) et occupent maintenant le champ reference 211, les bits devenus 
non significatifs du champ reference 201 sont mis a "1", les bits du marqueur, 
reference par les champs 200 et 205 restant inchanges. 

II convient de noter que la taille ou longueur en bits du marqueur 
se trouve ainsi augmentee d'un nombre egal a la valeur routing_width_30. 

On effectue alors un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du marqueur du chemin parcouru 
(identificateur du chemin parcouru) d'un nombre de bits qui est egal a la valeur 
routing_width_32, un nombre de bits egal a la valeur routing_width_32 des bits 
du marqueur se trouvant alors ecrit. 

Rappelons ici que le registre "routing_width_32" 94 associe a 
I'equipement d'interconnexion ou "portal" de sortie ("outbound portal" en 
terminologie anglo-saxonne) indique en fait la longueur en bits de 
I'identificateur ou label de routage sur le bus de sortie du paquet traite. 

La valeur des bits decrivant I'identificateur ou label de routage 
pour le descripteur du chemin parcouru (identificateur du chemin parcouru) 
sera determinee pendant I'etape 450 executee ulterieurement. 

Dans I'exemple de la figure 5, les bits d'informations des champs 
206, 207 et 208, decrivant le chemin parcouru, ont ete decale d'un nombre de 
bits egal a la valeur routing_width_32 (a gauche dans le champ 
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"source_Bus_ID" 81a de la figure 2 puis a droite dans le champ 
"destination_Bus_ID" 80a de la figure 2) et occupent alors respectivement les 
champs 209 pour le premier, 212 pour ie second et 213 pour le troisieme. Les 
champs 209 et 212, faisant auparavant partie du marqueur (et potentiellement 
5 aussi du chemin de destination), contiennent desormais des informations 
decrivant le chemin parcouru. Le champ 214 va etre affecte lors de I'operation 
decrite a I'etape 450. 

Lors des differentes phases mentionnees ci-dessus et qui ont lieu 
au cours de I'etape 421, le marqueur s'est egalement trouve deplace par 
10 rapport a sa position anterieure a I'interieur du registre "path_register". 

Si la valeur routing_width_32 est superieure a la valeur 
routing_width_30, alors la longueur du marqueur est reduite de la difference. A 
titre d'exemple, dans le cas decrit en figure 5, la valeur du registre 
"routing_width_32" vaut 6, la valeur du registre "routing_width_30" vaut 2, et la 
1 5 longueur du marqueur passe de 6 a 2. 

De fagon similaire, si la valeur routing_width_32 est inferieure a la 
valeur routing_width_30, alors la longueur du marqueur est augmentee de la 
difference. 

II convient de noter qu'en suivant cette regie, la longueur du 
20 marqueur reste superieure ou egale a la valeur 
max_width - routing_width + ERW (qui est toujours superieure ou egale a 
ERW) sur chaque bus traverse a condition que ceci soit le cas initialement. 

Ceci garantit que le marqueur reste identifiable par chaque pont. 
Dans I'exemple de la figure 5, le marqueur ou champ separateur auparavant 
25 constitue des champs 200 et 205, se trouve, apres passage du pont 66, 
represents par le champ 210, sa longueur etant passee de 6 a 2 bits. 

L'etape 421 est suivie par les etapes 430 de lecture du champ 
compose des (routing_width_32) bits du premier champ (equivalent de 
D_BuslD) du registre "pathjegister" et par le test 431 afin de determiner si 
30 tous les bits lus sont egaux a "1", c'est-a-dire si le paquet est arrive sur son bus 
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de destination. Dans I'affirmative, les etapes 440, 441, 442 et 443 sont 
executees, sinon on passe aux etapes 450 et 451 . 

Pour une meilleure comprehension de la description des etapes 
440 a 443 du traitement d'un paquet arrivant sur son bus de destination 59, le 
lecteur est prie de se referer a la figure 6. 

Lors de l'etape 440, le champ 203 de l'en-t§te du paquet 
asynchrone constituant I'identificateur virtuel du peripherique ou equipement 69 
destinataire dudit paquet sur le bus 59 est remplace par I'identificateur 
physique 221 qui lui correspond en utilisant la table de correspondance 
appropriee. 

L'etape 441 consiste a convertir I'identificateur du chemin 
parcouru contenu dans le registre "path_register" en index 223 ("offset") 
comme decrit ci-dessus en reference aux etapes 31 1 a 318 de la figure 10. 

Au cours de l'etape 442, le champ de I'en-tete identifiant le 
chemin parcouru est initialise avec la concatenation dudit index 223 ("offset") et 
du contenu 224 du registre "routing_label_32 M 93 (figure 4) en tenant compte 
du nombre des bits valides de I'identificateur ou label de routage, indique par le 
registre "routing_width_32" 94. 

Ensuite, au cours de I'etape 443, le champ de I'en-tete 220 
identifiant le bus de destination est initialise avec la valeur 3FF 16 . Ce traitement 
est suivi par l'etape 460. 

Au cours de I'etape 450 (lorsque les bits lus ne sont pas tous 
egaux a "1"), les bits identifiant le chemin parcouru du registre "path_register" 
(nombre indique par la valeur routing_width_32) sont initialises avec 
I'identificateur ou label de routage 93 stocke dans le registre "routing_label_32" 
associe a Pequipement d'interconnexion ou "portal" situe sur le bus de sortie du 
paquet traite. 

Pendant l'etape 451 les champs identifiant le bus source, c'est-a- 
dire les champs 212, 213, 214, 209 et le bus de destination, c'est-a-dire le 
champ 211 sont respectivement initialises avec le contenu du registre 
"path_register". Ce traitement est egalement suivi par l'etape 460. 
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L'etape 460 consiste a transferer le paquet sur le bus 58 (figure 
7), respectivement 59 (figure 6). Cette etape est suivie par l'etape 400 d'attente 
d'un nouveau paquet a traiter. 

La figure 12 est une vue schematique d'un reseau de bus lors de 
la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part. 

Ce reseau est compose des bus 501 a 505 interconnects par les 
ponts 506 a 51 1 . 

Le paquet de resolution d'adresse est envoye par un equipement 
source 513 afin d'obtenir un descripteur de chemin permettant ensuite 
d'acceder a I'equipement distant au moyen de paquets asynchrones tels que 
decrits dans le standard 1394-95. Ce paquet de resolution d'adresse est diffuse 
dans tout le reseau de bus ("broadcast" en terminologie anglo-saxonne). 

Un mecanisme complementaire peut etre mis en ceuvre au niveau 
de chaque equipement d'interconnexion ou "portal" d'un pont pour eviter que le 
paquet ne soit transmis plus d'une fois sur le meme bus et ainsi eviter tout 
bouclage infini dans le reseau de bus. Ce mecanisme, connu de I'homme du 
metier et decrit par exemple dans le livre "DATA NETWORKS, second edition, 
by Bertsekas Gallager, Prentice Hall International Editions, ISBN 0-13-201674- 
5" dans le chapitre intitule "Flooding and broadcasting", s'appuie par exemple 
sur les principes suivants : le paquet en cours de diffusion est identifie de fagon 
unique (par exemple a I'aide d'un numero d'identification unique qui est le 
numero EUI-64 de I'equipement source et d'un numero de sequence identifiant 
ce paquet de maniere unique dans ce meme equipement source), quand un 
equipement d'interconnexion ou "portal" diffuse ce paquet, il memorise 
certaines d'informations qui lui permettront ensuite de savoir si un paquet de 
diffusion qu'il a regu doit ou ne doit pas etre diffuse sur I'autre equipement 
d'interconnexion ou "portal" du pont considere, le cas echeant sur chacun des 
autres equipements d'interconnexion ou "portals" dudit pont, notamment en 
fonction d'une precedente reception de ce meme paquet. 
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Les equipements ^interconnexion ou "portals" doivent, entre 
autre, a cette fin gerer une table de verification dite de "diffusion" comme par 
exemple celle decrite a ia figure 15. 

Dans le cas ou ce paquet doit etre diffuse sur un bus, 
I'equipement d'interconnexion ou "portal" en question met a jour le descripteur 
de chemin qui permettra de diriger (router) directement le paquet reponse vers 
I'equipement qui est a I'origine du paquet de resolution d'adresse. La diffusion 
de ce paquet de resolution d'adresse est indiquee sur la figure 12 par les 
fleches 520, 521,522 et 523. 

Lorsque chaque equipement d'interconnexion ou "portal" d'un 
meme pont est regroupe dans un seul et meme dispositif tel que celui 
represente a la figure 3, une seule table de verification dite de "diffusion" 
commune peut etre utilisee pour tous les equipements d'interconnexion ou 
"portals" d'un pont donne. 

Sur un bus donne, chaque equipement d'interconnexion ou 
"portal", possedant en interne une table des numeros EUI-64 des differents 
equipements connectes sur le bus, est en charge de verifier, a la reception d'un 
paquet de resolution d'adresse, si I'equipement recherche est present ou non 
surle bus. 

Dans le cas positif, I'equipement d'interconnexion ou "portal" du 
pont 506 par exemple celui connecte au bus 501 stoppe la diffusion du paquet 
de resolution d'adresse et emet un paquet de donnees asynchrone de reponse 
530 vers le pont 508 qui transfere cette reponse sous la forme d'un paquet 531 
au pont 510, a destination de I'equipement qui est a I'origine du paquet de 
resolution d'adresse. 

Pour ce faire I'equipement d'interconnexion ou "portal" recupere 
dans le paquet de resolution d'adresse le descripteur de chemin mis a jour lors 
de la diffusion. 

Le paquet de donnees asynchrone de reponse faisant route vers 
I'equipement 513 a I'origine du paquet de resolution d'adresse va construire le 
descripteur de chemin recherche. II en est de meme pour I'equipement 
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^interconnexion ou "portal" du pont 507 qui va emettre un paquet de donnees 
asynchrone de reponse 533 vers le pont 510 (figure 12). 

II appartient a chaque equipement d'interconnexion ou "portal" 
des ponts du bus 504 , ou se situe I'equipement 513 a I'origine du paquet de 
resolution d'adresse, de reconnaitre les differents paquets de donnees 
asynchrones de reponse, de les filtrer et de n'en envoyer qu'un seul, reference 
534 sur la figure 12, vers I'equipement 513, dans le cas ou celui-ci ne viendrait 
pas deja d'un autre equipement d'interconnexion ou "portal" relie au bus 504. 

Pour ce faire, I'equipement d'interconnexion ou "portal" doit 
memoriser le fait que la requete de resolution d'adresse a ete suivie d'une 
reponse, par exemple en sauvegardant a partir de la premiere reponse recue, 
et ce pendant une certaine duree, des donnees comme le numero EUI-64 de 
I'equipement recherche et le numero de sequence identifiant le paquet de 
resolution d'adresse de maniere unique dans cet equipement source, et en les 
comparant avec celles effectivement regues dans les autres paquets reponses. 
Les eventuels paquets de donnees asynchrones de reponse s'averant etre des 

doublons sont simplement ignores. 

La figure 13 est une vue schematique representant la structure 

d'un paquet de donnees de resolution d'adresse 550. Ce format de paquet est 

preferentiellement base sur le format d'un paquet global de flux asynchrone (en 

terminologie anglo-saxonne "Global Asynchronous Stream Packet" ou en 

abrege "GASP"). 

Les champs 551 a 556 denommes "datajength", "tag", channel", 

"A 16 ", "sy" et "header_CRC" ont des valeurs constantes definies par le comite 

de normalisation 1394. 

La valeur du champ 557 "sourceJD" permet de specifier I'adresse 

de I'equipement d'interconnexion ou "portal" emetteur du paquet. 

Les champs 558 a 560 denommes "specifiier_ID_hi", 

"specifiierJDJo", et "version" ont des valeurs constantes definies par le comite 

de normalisation 1394. 
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Les champs 561 a 568 constituent une partie denomrnee "champ 
de donnees" ("data field" en terminologie anglo-saxonne) d'un paquet GASP et 
sont utilises de la facon indiquee ci-apres. 

Le champ descripteur de chemin 561 ("path_descriptor" en 
5 terminologie anglo-saxonne), represente sur 20 bits, contient I'information de 
routage elaboree lors du cheminement du paquet de resolution d'adresse vers 
I'equipement destination recherche. La valeur de ce champ est done 
representative du chemin parcouru. La taille utile de ce champ est definie a 
partir de la valeur des champs "max_width" 97, "routing_width_30" 92, et 

10 "routing_width_32" 94 (figure 4) et des traitements effectues sur le chemin 
parcouru tels qu'explicites lors de la description de I'etape 421 de la figure 1 1 . 
Par exemple, lorsqu'un paquet de resolution d'adresse present sur le bus 56 de 
la figure 1 est susceptible d'etre transfere par le pont 66 sur le bus 58 et que le 
champ 561 comporte, par exemple, les champs 200 et 205 a 208 de la figure 5, 

15 alors le contenu du champ 561 sera remplace par les champs 210, 209 et 212 
a 215 lors du transfert via le pont 66. 

Le champ denomme "sequence_number" ("numero de 
sequence") et note 562, represente sur 12 bits, permet d'identifier ce paquet de 
maniere unique dans I'equipement source a I'origine de la requete de resolution 

20 d'adresse. 

Les champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 
("EUi-64 source haut et bas") et notes respective ment 563 et 564, representes 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement a I'origine de 
ce paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier 
25 de maniere unique I'equipement source a I'origine de la requete de resolution 
d'adresse. 

Les champs denommes "Dev_EUI_64_hi" et "Dev_EUI_64Jo" 
("EUI-64 equipement recherche haut et bas") et notes respectivement 565 et 
566, representes chacun sur 32 bits, decrivent le numero EUI-64 de 
30 I'equipement recherche par I'equipement a I'origine de ce paquet de resolution 
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d'adresse. Ce numero EUI-64 identifie de maniere unique I'equipement 
recherche. 

Quand un equipement souhaite communiquer avec un 
equipement distant, celui-ci positionne, entre autres, les champs 563 et 564 
("Src_EUI_64_hi" et "Src_EUI_64_lo") avec son numero EUI-64, et le champ 
numero de sequence 562 avec une valeur unique pour cet equipement (valeur 
incrementee, par exemple, apres chaque emission d'un tel paquet). 

En sauvegardant, pendant une duree predeterminee par exemple 
egale a une seconde, ce numero de sequence pour chaque equipement 
emetteur d'un paquet de resolution d'adresse, chaque equipement 
d'interconnexion ou "portal" du reseau peut ainsi eviter d'emettre a nouveau ce 
paquet sur le(s) bus adjacent(s). 

Le champ denomme "response packet type specific information" 
("information specifique pour le paquet reponse") et note 567, represente sur 
48 bits, contient I'information necessaire pour construire le paquet reponse en 
reponse au paquet de resolution d'adresse. Cette information est position nee 
par I'equipement emetteur du paquet de resolution d'adresse. Ce champ 
specifie notamment, dans le cas ou le paquet reponse est base, par exemple, 
sur un paquet primaire asynchrone ("asynchronous primary packet" en 
terminologie anglo-saxonne) de type ecriture (decrit dans la norme 1394-95), 
I'adresse de destination dans I'equipement source qui est a I'origine du paquet 
de resolution d'adresse, adresse a laqueile I'equipement destinataire recherche 
pourra ecrire des donnees en reponse a la requete. Le paquet de reponse est 
par exemple un paquet de type requete d'ecriture d'un bloc de donnees ("write 
request for data block" en terminologie anglo-saxonne). 

Un champ denomme "reserved" ("reserve") et note 568, 
represente sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 

La valeur d'un champ denomme "data_CRC" et note 569 est 
calculee en fonction de la valeur des champs 557 a 568 selon des regies 
predeterminees par le comite de normalisation 1394. 
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La figure 14 est une vue schematique representant la structure 
d'un paquet de donnees asynchrone 580 de reponse au paquet de resolution 
d'adresse 550 decrit precedemment. Le format d'un tel paquet est largement 
decrit dans le standard 1394-95 et est illustre en figure 2. Seuls les champs 
5 utiles dans le cadre du present document sont decrits ci-apres. 

Comme il a ete mentionne precedemment, la valeur d'un champ 
denomme "tCode" et note 585 peut par exemple correspondre a une requete 
du type "write request for data block". 

Un champ denomme "reserved" ("reserve") et note 590, 
10 represente sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 

Un champ denomme "sequence_number" ("numero de 
sequence") et note 591, represente sur 12 bits, permet d'identifier le paquet de 
maniere unique dans I'equipement qui est a I'origine de la requete de resolution 
d'adresse. 

15 Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 

("EUI-64 source haut et bas") et notes respectivement 592 et 593, represent.es 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement a I'origine du 
paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier de 
maniere unique I'equipement qui est a I'origine de la requete de resolution 

20 d'adresse. 

Les champs 592, 593 ("Src_EUI_64_hi" et "Src_EUI_64_lo") et le 
champ 591 ("sequence_number") permettent notamment a chaque equipement 
d'interconnexion ou "portal" sur le bus dit "source" (bus ou se situe 
I'equipement qui est a I'origine de la requete de resolution d'adresse) de savoir 

25 si une reponse a deja ete envoyee a I'equipement qui est a I'origine de la 
requete de resolution d'adresse. 

Les equipements d'interconnexion ou "portals" sur le bus "source" 
doivent pour cela gerer une table de verification dite de "reponse" comme par 
exemple celle decrite en figure 15. 

30 On notera que la detection et le traitement du bouclage ("loop 

detection" en terminologie anglo-saxonne) concerne une amelioration apportee 
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au procede de routage d'un paquet de resolution d'adresse et qui utilise des 
precedes decrits dans I'etat de I'art. 

En effet, un traitement par defaut du bouclage est mis en oeuvre 
par le procede de routage d'un paquet de resolution d'adresse lors du 
5 traitement associe au champ 561 : lorsque la totalite de la zone utile du champ 
561 du paquet de resolution d'adresse est utilisee pour decrire le chemin 
parcouru, le procede de transfert du paquet d'un bus a I'autre est stoppe. 

Ainsi, le procede de transfert de paquet va consommer, par 
insertion d'identificateurs ou labels de routage lors de chaque boucle, une 
10 partie de la zone utile du champ 561 du paquet de resolution d'adresse, jusqu'a 
remplir la totalite du champ, ce qui a pour effet de mettre fin au transfert du 
paquet. 

La figure 15 est une vue schematique detaillee representant une 
table de verification 600 stockee dans la memoire RAM de la figure 3. Ce type 
15 de table peut etre utilise par les deux types de verification precedemment 
decrits : 

- diffusion d'un paquet de resolution d'adresse d'une part, 

- generation d'un seul et unique paquet de reponse correspondant 
a un paquet de resolution d'adresse sur le bus ou se situe I'equipement qui est 

20 a I'origine de ce paquet de resolution d'adresse. 

La figure 15 illustre par exemple une table de verification 
contenant un nombre limite d'enregistrements elementaires notes 601 a 605. 

Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo" 
("EUI-64 source haut et bas") et notes respectivement 610 et 611, represent.es 
25 chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement qui est a 
I'origine du paquet de resolution d'adresse. Ce numero EUI-64 est utile pour 
identifier de maniere unique I'equipement qui est a I'origine du paquet de 
resolution d'adresse. 

Un champ denomme "sequence_number" ("numero de 
30 sequence") et note 612, represents sur 12 bits, permet d'identifier ce paquet de 
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maniere unique dans I'equipement qui est a I'origine du paquet de resolution 
d'adresse. 

Un champ denomme "management" ("gestion") et note 613, 
represents sur 20 bits, permet d'associer des informations a chaque 
5 enregistrement de la table selon le type de la table envisagee. 

Dans le cas d'une table de verification dite de "diffusion" (utilisee 
pour gerer la diffusion d'un paquet de resolution d'adresse de telle sorte que ce 
paquet soit transmis sur chaque bus du reseau, une et une seule fois), le 
champ "management" peut par exemple contenir une information indiquant si 
10 un paquet de resolution d'adresse a deja ete soit regu par I'equipement 
d'interconnexion ou "portal", soit transmis par celui-ci (une valeur booleenne 
peut par exemple etre suffisante). 

Dans le cas d'une table de verification dite de "reponse" (utilisee 
pour gerer la non-duplication d'une reponse vers I'equipement qui est a I'origine 
15 d'un paquet de resolution d'adresse), le champ "management" peut, par 
exemple, contenir une information indiquant si un paquet reponse a deja ete 
soit regu par I'equipement d'interconnexion ou "portal", soit transmis par celui-ci 
(une valeur booleenne peut par exemple etre suffisante). 

Selon une premiere variante non decrite ici, un compteur pourrait 
20 apporter des informations supplementaires sur le fait que plusieurs reponses, 
c'est-a-dire plusieurs descripteurs de chemin, existent et done qu'un choix 
pourrait etre fait sur le descripteur de chemin a retenir selon des criteres 
predefinis comme, par exemple, le plus court chemin. 

Cette variante impose alors de definir un protocole de 
25 communication entre les differents equipements d'interconnexion ou "portals" 
afin d'effectuer le changement de descripteur de chemin a utiliser. 

Dans une deuxieme variante non decrite ici, e'est "I'alpha portal" 
qui centralise toutes les reponses regues au niveau du bus local ou se situe 
I'equipement qui est a I'origine du paquet de resolution d'adresse, qui decide 
30 de retenir, selon des criteres predefinis comme, par exemple, le plus court 
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chemin, un descripteur de chemin, et qui n'envoie finalement qu'un seul paquet 
reponse vers I'equipement qui est a I'origine du paquet de resolution d'adresse. 

Une troisieme variante consiste a utiliser comme informations 
dans le champ "management", en plus de I'indicateur de passage de paquet de 
5 resolution d'adresse ou de paquet reponse deja transmis, une valeur indiquant 
par exemple la duree en unites de temps correctement definie ("timeout" en 
terminologie anglo-saxonne) au-dela de laquelle cet enregistrement n'est plus 
significatif et peut done etre detruit. 

Une quatrieme variante consiste a n'utiliser qu'une seule table de 
10 verification a la fois pour la "diffusion" et les "reponses". Dans ce cas, le champ 
"management" peut se decomposer entre deux champs, I'un contenant des 
informations relatives a la diffusion de paquet de resolution d'adresse, I'autre 
aux paquets reponses a ce paquet de resolution d'adresse. 

La figure 16 est une vue schematique de I'algorithme d'un 
15 precede de reception d'un paquet de resolution d'adresse au niveau d'un 
equipement d'interconnexion ou "portal" d'un pont. 

Les instructions ou etapes du procede sont stockees dans la 
memoire ROM de chaque pont du reseau. 

Au niveau du bus source, le paquet de resolution d'adresse emis 
20 par I'equipement source est decrit en reference a la figure 1 3. 

Ce paquet doit etre compris par les equipements d'interconnexion 
ou "portals" sources qui vont le traduire en un paquet de resolution d'adresse 
tel que represents sur la figure 13. 

Au cours d'une etape 701, un paquet de resolution d'adresse est 
25 recu au niveau d'un equipement d'interconnexion ou "portal". Au cours de 
I'etape 702, les champs "EUI-64 source" et "sequence_number" decrits 
precedemment en reference a la figure 13 sont lus. 

Au cours de I'etape 703, le procede prevoit de verifier si un 
enregistrement elementaire ayant le numero EUI-64 source qui vient d'etre lu 
30 dans le paquet recu existe deja dans la table de verification 600, representee a 
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la figure 15, a partir des champs EUI-64 source haut et bas presents dans cette 
table. 

Dans le cas ou I'enregistrement n'existe pas, au cours de I'etape 
704, le precede prevoit d'en creer un avec les valeurs des champs "EUI-64 
5 source" et "sequence_number" lus dans le paquet recu, par exemple 
I'enregistrement 601 represents a la figure 15, puis se poursuit par I'etape 709. 

Dans la cas ou I'enregistrement existe deja dans la table de 
verification, au cours de I'etape 705, le precede prevoit de verifier que le 
numero de sequence lu a partir du paquet recu est strictement superieur au 
10 numero de sequence courant de I'enregistrement, par exemple note 612 en 
figure 15. 

Dans le cas negatif (plus petit ou egal), lors de I'etape 706, le 
paquet de resolution d'adresse est ignore ; il se peut par exemple que ce soit 
un paquet plus ancien et qui, de toute facon, n'est plus valide. 

15 Dans le cas positif, le precede precede a une mise a jour du 

numero de sequence de I'enregistrement avec celui lu du paquet recu, au 
cours de I'etape 707, ainsi que des informations de gestion (comme celles 
precedemment mentionnees, telles que, par exemple, une valeur booleenne 
indiquant si un paquet de resolution d'adresse a deja transite sur le bus vu par 

20 I'equipement d'interconnexion ou "portal", et/ou un compteur indiquant combien 
de paquets identiques de resolution d'adresse ont ete detecte sur le bus vu par 
I'equipement d'interconnexion ou "portal", et/ou une valeur indiquant par 
exemple la duree en unites de temps correctement definie ("timeout" en 
terminologie anglo-saxonne) au-dela de laquelle cet enregistrement n'est plus 

25 significant et peut done etre detruit), au cours de I'etape 708. 

Au cours de I'etape 709, le precede prevoit de verifier si 
I'equipement d'interconnexion ou "portal" a connaissance de I'equipement 
recherche, identifie par les champs "Dev_EUI_64_hi" et "Dev_EUI_64_lo", 
notes respectivement 565 et 566 sur la figure 13. 

30 Autrement dit, dans le cas ou I'equipement recherche se situe sur 

le meme bus (ce bus est dit "bus destination") que I'equipement 
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d'interconnexion ou "portal" en question, alors ce dernier possede son numero 
EUI-64 dans une table interne qui n'est pas decrite dans ce contexte car elle 
est definie dans le cadre des specifications en cours du standard pont 1394. 

Dans le cas positif, au cours de I'etape 710, le precede prevoit 
5 d'effectuer les operations de creation et/ou de mise a jour dans la table de 
routage precedemment decrite en reference aux figures 8 et 9, puis d'initier 
renvoi d'un paquet reponse 580, tel que decrit en reference a la figure 14, audit 
paquet de resolution d'adresse. 

Les champs de ce paquet reponse 580 sont notamment 
10 positionnes en utilisant les valeurs des champs du paquet de resolution 
d'adresse de la facon suivante : 

- le champ descripteur de chemin 561 est utilise pour positionner 
les champs 581 , 582, 587 et 588, 

-le champ "response_packet_type_specific_information" 567 est 
1 5 utilise pour positionner le champ de meme nom 589, 

- le champ "sequence_number" 562 est utilise pour positionner le 
champ de meme nom 591 , 

- les champs "Src_EUI_64_hi" et "Src_EUI_64_lo" respectivement 
notes 563 et 564 sont utilises pour positionner les champs de memes noms 

20 592 et 593. 

Dans le cas negatif, au cours de I'etape 71 1 , le precede prevoit de 
verifier si I'equipement d'interconnexion ou "portal" a recu le paquet de 
resolution d'adresse du bus sur lequel il est situe (sinon cela signifie que le 
paquet a ete recu du (ou d'un) "portal" du pont auquel appartiennent ces 
25 "portals"). 

Dans le cas positif (paquet regu du bus), le precede mis en ceuvre 
au niveau de I'equipement d'interconnexion ou "portal" prevoit d'envoyer, au 
cours de I'etape 712, le paquet a (aux) l* (les) equipement(s) d'interconnexion 
ou "portal(s)" constituant le pont. 
30 Dans le cas negatif (paquet recu de I'equipement d'interconnexion 

ou "portal"), le precede mis en ceuvre au niveau de I'equipement 
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d'interconnexion ou "portal", au cours de I'etape 713, met a jour le descripteur 
de chemin du paquet de resolution d'adresse et I'envoie sur le bus, propageant 
ainsi la diffusion du paquet a travers le reseau de bus. 

Le descripteur de chemin ayant une taille finie, lorsque ce 
5 descripteur de chemin du paquet de resolution d'adresse ne peut plus etre mis 
a jour, la transmission ou diffusion dudit paquet de resolution d'adresse est 
stoppee. Ce traitement permet de controler le mecanisme de propagation du 
paquet de resolution d'adresse et, par la meme, permet de detecter et de 
resoudre les problemes de bouclage. 

10 Suite aux etapes 710, 712 et 713, le traitement du paquet de 

resolution d'adresse se trouve alors termine et le procede revient a son etape 
initiale (701) d'attente d'un nouveau paquet. 

La figure 17 est une vue schematique de I'algorithme d'un 
procede de reception d'un paquet de donnees de reponse, suite a remission 

15 d'un paquet de resolution d'adresse, au niveau d'un equipement 
d'interconnexion ou "portal" d'un pont situe sur le bus ou se trouve i'equipement 
qui est a I'origine du paquet de resolution d'adresse. 

Les instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM du pont considere. 

20 La reception d'un paquet de donnees de reponse peut revetir 

deux formes : soit il s'agit d'un paquet de donnees de reponse emis par un 
equipement d'interconnexion ou "portal" distant signifiant la presence de 
I'equipement recherche sur son bus, soit il s'agit d'un paquet de donnees de 
reponse emis par un equipement d'interconnexion ou "portal" local au bus 

25 source et, dans ce cas, il s'agit du seul et unique paquet envoye a I'equipement 
qui est a I'origine du paquet de resolution d'adresse. 

Au cours d'une etape 751, le procede mis en ceuvre au niveau de 
I'equipement d'interconnexion ou "portal" du bus oil se trouve I'equipement qui 
est a I'origine du paquet de resolution d'adresse, prevoit d'attendre un 

30 evenement associe a un paquet de reponse, c'est-a-dire ou bien la reception 
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d'un paquet de reponse ou alors I'ecoulement d'une duree d'attente maximum 
predefinie depuis 1'emission du paquet de resolution d'adresse. 

Au cours de I'etape suivante 752, le procede prevoit de verifier si 
I'evenement en question est effectivement un paquet de reponse au paquet de 
5 resolution d'adresse. 

Dans le cas positif, au cours de I'etape 753, le procede prevoit de 
verifier si le type du paquet de reponse recu est un paquet emis par un 
equipement d'interconnexion ou "portal" local au bus (paquet reponse unique 
envoye a I'equipement qui est a I'origine du paquet de resolution d'adresse). 
10 Dans le cas negatif, au cours de I'etape 754, le paquet de 

reponse est acquitte comme decrit dans le standard 1394-95 et le paquet de 
reponse etant base sur un paquet primaire asynchrone de type requete 
("request" en terminologie anglo-saxonne), celui-ci doit §tre acquitte par un 
paquet de type reponse ("response" en terminologie anglo-saxonne). 
15 Dans le cas negatif de la verification faite a I'etape 752, celle-ci 

est suivie par I'etape 760. 

Au cours de I'etape 755, le procede prevoit de verifier si un 
paquet de reponse pour le paquet de resolution d'adresse a deja ete recu par 
I'equipement d'interconnexion ou "portal" ou detecte sur le bus "source" ou si 
20 un acquittement negatif n'a pas deja ete genere sur le bus source. 

Dans le cas negatif ou, a priori, aucun paquet reponse n'est 
attendu, au cours de I'etape 758, le procede prevoit d'ignorer le paquet et de 
revenir a I'etape initiale 751 . 

Dans le cas positif, ou effectivement un paquet reponse est 
25 attendu, au cours de I'etape 756, le procede prevoit de memoriser la reception 
ou la detection d'un paquet reponse. 

Puis, au cours de I'etape 757, dans le cas ou le paquet reponse 
precedemment recu n'etait pas deja un paquet reponse unique envoye a 
I'equipement qui est a I'origine du paquet de resolution d'adresse, le procede 
30 prevoit d'envoyer un paquet reponse unique a I'equipement qui est a I'origine 
du paquet de resolution d'adresse. 
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Au cours de I'etape 760, le precede prevoit de verifier si la duree 
d'attente maximum predefinie s'est ecoulee depuis 1'emission du paquet de 
resolution d'adresse. La duree d'attente doit etre correctement choisie, par 
exemple de telle sorte qu'elle soit superieure au temps du plus long parcours 
5 alier d'un paquet de resolution d'adresse additionne au temps de parcours de 
I'eventuel paquet reponse correspondant. Dans le cas negatif, le processus 
traite le cas d'erreur au cours de I'operation 761 . Dans le cas positif, I'etape 760 
est suivie d'une etape 762. 

Au cours de I'etape 762, si aucune operation n'a ete detectee sur 

10 le bus source, le precede prevoit d'envoyer a I'equipement qui est a I'origine du 
paquet de resolution d'adresse un paquet de reponse signalant qu'aucun 
equipement repondant au champ "EUI-64 source" precise dans le paquet de 
resolution d'adresse n'a ete trouve, et ce, pendant la duree d'attente maximum 
autorisee. Le precede prevoit ensuite de revenir a I'etape initiale 751 . 

15 La figure 18 est une vue schematique de I'algorithme d'un 

precede de determination d'identificateurs de ponts ou labels de routage au 
niveau d'un bus en fonction de la capacite du bus. Ce precede permet 
notamment de gerer la longueur des identificateurs des ponts connectes au 
bus considere. Les etapes ou instructions de ce precede sont stockees dans 

20 une memoire ROM d'au moins un des ponts du reseau relies a un bus. 

Plus particulierement, cet algorithme est stocke dans une 
memoire de I'equipement d'interconnexion du reseau qui est appele "alpha 
portal" dans la norme IEEE 1394. 

II convient de noter que le pont considere relie deux parties d'un 

25 reseau entre elles, I'une des parties, dite premiere partie, etant constituee du 
bus relie audit pont, I'autre partie, dite seconde partie, etant constituee, par 
exemple, d'un autre bus relie a ce pont. 

Au cours d'une etape 901, le precede prevoit de detecter un 
evenement indiquant une premiere initialisation d'un bus auquel le pont est 

30 connecte. En outre, on determine la longueur eldmentaire (ERW) d'un 
identificateur de routage qui constitue une caracteristique du reseau. Dans le 
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mode prefere de realisation de la presente invention, cette valeur est 
predeterminee (par exemple egale a 2) et est stockee dans la memoire ROM 
du pont. Dans des variantes non representees, une determination dynamique 
de cette valeur en fonction des caracteristiques du reseau peut etre envisagee. 
5 II suffit de garantir que la meme valeur ERW soit connue par tous les ponts du 
reseau. 

Au cours de I'etape 902, on determine pour ledit bus la capacite 
en bande passante (plus grande bande passante commune a tous les 
peripheriques presents sur ce bus). 
10 II convient de noter que la capacite en bande passante ou debit 

binaire du bus constitue une caracteristique de celui-ci. 

Ensuite, au cours de I'etape 903, le procede prevoit de verifier, 
pour le bus, si la capacite dudit bus en bande passante est inferieure au debit 
binaire reference S400 par la norme 1394-95 (S400 signifiant un debit de 
15 393,216 Mbit/s). 

Dans le cas negatif, au cours de I'etape 904, il est ve>rifie, pour le 
bus, si cette capacite du bus en bande passante est inferieure au debit 
reference S800 par le standard 1394-95 (S800 signifiant un debit de 786,432 
Mbit/s). 

20 Selon la valeur de la caracteristique de la premiere partie du 

reseau, a savoir la capacite en bande passante dudit bus, et selon la 
caracteristique ERW du reseau, le procede prevoit de determiner, d'une part, la 
longueur (BRW) en bits de I'identificateur ou label de routage au niveau dudit 
bus au cours des etapes 905, 907 et 909, puis, d'autre part, le nombre 

25 maximum de ponts ou d'equipements d'interconnexion de ponts ("portals") 
autorises sur ledit bus ("max_bridge" en terminologie anglo-saxonne), ceci au 
cours des etapes 906, 908 et 910. La longueur BRW doit etre un multiple entier 
de la valeur ERW stockee dans le registre 100 de la figure 4, et elle est 
inferieure ou egale a la valeur max_width contenue dans le registre 97. 

30 On notera que pour une longueur en bits de I'identificateur ou 

label de routage de n*ERW bits, seulement (2 ERW -1) n valeurs d'identificateurs 
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ou labels de routage sont autorisees car une valeur particuliere dite de 
separation (marqueur ou separateur) est reservee. Dans le mode prefere de 
realisation de I'invention, le marqueur est constitue par une sequence de bits 
egaux a "1" d'une longueur superieure ou egale a la valeur ERW. Lorsque la 
5 taille du marqueur est ajustee a la valeur ERW cela permet de coder davantage 
d'identificateurs de ponts dans I'en-tete du paquet entre la source et la 
destination de ce dernier dans le reseau. 

Au cours de I'etape 911, on affecte un identificateur de routage 
constant et unique a I'equipement d'interconnexion ou "portal" du pont 

10 connecte au bus. L'identificateur ainsi affecte a une longueur qui est celle 
venant d'etre determinee au cours des etapes 905, 907 , 909. Cette valeur 
d'identificateur de routage est avantageusement calculee de facon similaire par 
tous les equipements d'interconnexion ou "portals" a partir de la connaissance 
des identificateurs virtuels associes a chaque equipement d'interconnexion ou 

15 "portal" du bus considere. Par exemple, la valeur de l'identificateur de routage 
est definie pour chaque equipement d'interconnexion par ordre croissant de la 
valeur de l'identificateur virtuel et, ainsi, Palpha portal" se verra assigner un 
identificateur de routage de valeur '0'. 

Au cours de I'etape 912, le precede prevoit de verifier, pour le 

20 bus, si la valeur de l'identificateur de routage affecte a I'equipement 
d'interconnexion ou "portal" du pont en question est inferieure au nombre 
maximum de ponts autorises sur ledit bus. 

Dans le cas negatif, au cours de I'etape 914, le pont est 
positionne dans I'etat "desactive" ("disabled" en terminologie anglo-saxonne) et 

25 I'algorithme se poursuit par I'etape 915 et une valeur particuliere representative 
de cet "etat" est definie pour l'identificateur de routage de I'equipement 
d'interconnexion ou "portal" considere. 

Par exemple, si le codage des identificateurs a lieu sur 2 bits, on 
ne peut pas identifier plus de trois ponts dans un champ d'informations 

30 d'identifications. 
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Ainsi, si Ton connecte un quatrieme pont au bus, celui-ci ne sera 
pas gere au niveau du bus et aucun identificateur de routage valide ne lui sera 
affecte (pont "desactive"). 

Dans le cas positif, au cours de l'etape 913, les differents 
parametres et variables permettant la mise en ceuvre du routage decrit dans le 
present document sont initialises. 

L'etape 915 consiste a attendre un evenement de type 
initialisation de bus ("bus reset" en terminologie anglo-saxonne). 

Dans le cas ou cet evenement se produit, au cours de l'etape 916, 
Palgorithme verifie si la configuration des ponts au niveau du bus a change (par 
exemple un pont a ete nouvellement connecte ou un pont existant a ete 
deconnecte). 

Dans le cas negatif, on revient a l'etape precedente 915. 

Dans le cas positif, au cours de l'etape 917, la mise en ceuvre du 
routage decrit dans le present document est suspendue, de telle sorte que plus 
aucun paquet ne peut entrer sur le bus ou sortir de ce bus par I'intermediaire du 
pont. 

L'etape 918 consiste a attendre pendant une duree suffisante 
predefinie ("time out" en terminologie anglo-saxonne) afin que tout peripherique 
utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
peripherique "distant" considere ce descripteur de chemin comme obsolete. En 
consequence, le peripherique doit par exemple generer a nouveau un paquet 
de resolution d'adresse avant de pouvoir reprendre toute communication. 

L'etape 902 est ensuite executee. 

Une autre variante, non decrite ici consiste, par exemple, pendant 
I'intervalle de temps entre la suspension de la mise en oeuvre du routage decrit 
dans le present document (etape 917) et la revalidation de cette mise en ceuvre 
du routage, a acquitter d'une facon particuliere tout paquet desirant transiter via 
le pont. 

La figure 19 est une vue schematique de I'algorithme d'un 
procede de determination d'identificateurs de ponts ou labels de routage au 
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niveau d'un bus en fonction du nombre de ponts et done d'equipements 
d'interconnexion ou "portals" connectes au bus. Ce procede permet notamment 
de gerer la longueur des identificateurs de ponts connectes au bus considere. 
Les etapes ou instructions de ce procede sont stockees dans une memoire 
5 ROM d'au moins un des ponts du reseau relies a un bus. 

Plus particulierement, cet algorithme est stocke dans une 
memoire de I'equipement d'interconnexion du reseau qui est appele "alpha 
portal" dans norme IEEE 1394. 

L'algorithme de ce procede ressemble fortement a celui decrit 
10 precedemment en reference a la figure 18, la difference portant principalement 
sur la caracteristique de la premiere partie du reseau ou bus utilisee pour 
decider de la longueur de I'identificateur ou label de routage a utiliser. 

Dans la figure 18, cette caracteristique est la capacite en bande 
passante ou debit binaire d'un bus donne, I'objectif etant d'eviter d'autoriser un 
15 trop grand nombre de communications transitant sur ledit bus. A cette fin, un 
pont est mis dans I'etat "desactive" pour qu'il ne puisse plus faire transiter 
d'information. On note que dans le procede de la figure 18, on cherche a 
prevenir toute congestion. 

Dans l'algorithme de la figure 19, la caracteristique du bus qui est 
20 prise en compte est le nombre de ponts ou d'equipements d'interconnexion ou 
"portals" connectes sur ledit bus. En fonction du nombre de ponts sur ledit bus, 
un certain nombre de bits est necessaire afin de pouvoir tous les identifier de 
facon unique. 

Cet algorithme veille egalement a ne pas utiliser de bit inutilement 
25 pour cette identification. L'algorithme permet aussi de mettre un pont dans I'etat 
"desactive" dans le cas ou trop de bits sont necessaires pour ('identification 
dudit pont. 

D'autres variantes, non decrites dans le present document, 
peuvent aisement etre envisagees a partir d'autres caracteristiques d'une partie 
30 du reseau, par exemple un bus, qui seront prises en compte dans la decision 
d'affectation de la longueur de I'identificateur ou label de routage a utiliser. 
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Au cours d'une etape 951, on detecte un evenement indiquant 
une premiere initialisation d'un bus auquel le pont est connecte. On determine 
une caracteristique du reseau, a savoir la valeur ERW, de facon identique a la 
description faite pour l'etape 901 sur la figure 18. 
5 L'etape 952, determine pour le bus (premiere partie du reseau) ie 

nombre de ponts ou d'equipements d'interconnexion ou "portals" presents sur 
ce bus et constituant une caracteristique dudit bus. 

Ensuite, le procede prevoit de verifier, pour ce bus, si le nombre 
de ponts est inferieur a 3 au cours de l'etape 953, sinon s'il est inferieur a 9 au 

10 cours de l'etape 954 et sinon s'il est inferieur a 27 au cours de l'etape 955. 
Dans la negative, I'algorithme se poursuit par I'etape 965. 

Selon la valeur de la caracteristique de la premiere partie du 
reseau, a savoir le nombre de ponts connectes audit bus et selon la 
caracteristique ERW du reseau, on determine, d'une part, la longueur (BRW) 

15 en bits de I'identificateur ou label de routage au niveau dudit bus au cours des 
etapes 956, 958 et 960, puis d'autre part, le nombre maximum de ponts ou 
d'equipements d'interconnexion ou "portals" autorises sur ledit bus 
("max_bridge" en terminologie anglo-saxonne), ainsi que le nombre minimal 
d'equipements d'interconnexion ou "portals" pour ladite longueur en bits de 

20 I'identificateur ou label de routage ("min_bridge" en terminologie anglo- 
saxonne), ceci au cours des etapes 957, 959 et 961. 

La longueur BRW doit etre un multiple entier de la valeur ERW 
stockee dans le registre 100 de la figure 4, et elle est inferieure ou egale a la 
valeur max_width contenue dans le registre 97. 

25 On notera que pour une longueur en bits de I'identificateur ou 

label de routage de n*ERW bits, seulement (2 ERW -1) n valeurs d'identificateurs 
ou labels de routage sont autorisees car une valeur particuliere dite de 
separation (marqueur ou separateur) est reservee. Dans le mode prefere de 
realisation de I'invention, le marqueur est constitue par une sequence de bits 

30 egaux a "1 " d'une longueur superieure ou egale a la valeur ERW. 
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Lorsque cette longueur est egale a la valeur ERW les avantages 
sont les memes que ceux indiques lors de la description faite en reference a la 
figure 18.Au cours de I'etape 962, on affecte un identificateur de routage 
constant et unique a I'equipement d'interconnexion ou "portal" du pont 
5 connecte au bus. L'identificateur ainsi affecte a une longueur qui est celle 
venant d'etre determinee au cours des etapes 956, 958, 960. 

Cette valeur d'identificateur de routage est avantageusement 
calculee de fagon similaire par tous les equipements d'interconnexion ou 
"portals", a partir de la connaissance des identificateurs virtuels associes a 
10 chaque equipement d'interconnexion ou "portal" du bus considere. 

Par exemple, la valeur de l'identificateur de routage est definie 
pour chaque equipement d'interconnexion par ordre croissant de la valeur de 
l'identificateur virtuel et, ainsi, Halpha portal" se verra assigner un identificateur 
de routage de valeur '0'. 
15 Au cours de I'etape 963, le precede prevoit de verifier, pour ledit 

bus, si la valeur de l'identificateur de routage affecte a I'equipement 
d'interconnexion ou "portal" du pont en question est inferieure au nombre 
maximum de ponts autorises sur ledit bus. 

Dans le cas negatif, au cours de I'etape 965, le pont est 
20 positionne dans I'etat desactive ("disabled" en terminologie anglo-saxonne) et 
une valeur particuliere representative de cet "etat" est definie pour 
l'identificateur de routage de I'equipement d'interconnexion ou "portal" 
considere, puis I'algorithme se poursuit par I'etape 966. 

Dans le cas positif, au cours de I'etape 964, les differents 
25 parametres et variables permettant la mise en oeuvre du routage decrit dans le 
present document sont initialises. 

L'etape 966 consiste a attendre un evenement de type 
initialisation de bus ("bus reset" en terminologie anglo-saxonne). Dans le cas 
ou cet evenement se produit, au cours de I'etape 967, I'algorithme verifie si la 
30 configuration des ponts au niveau du bus a change (par exemple un pont a ete 
nouvellement connecte ou un pont existant a ete deconnecte) et si le nombre 
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de ponts ou equipements d'interconnexion ("portals") est en dehors de 
I'intervalle defini precedemment par min_bridge et max_bridge. 

Dans le cas negatif, ralgorithme revient a l'etape precedente 966. 

Dans le cas positif, au cours de I'etape 968, la mise en ceuvre du 
5 routage decrit dans le present document est suspendue de telle sorte que plus 
aucun paquet ne peut entrer sur le bus ou sortir de ce bus par I'intermediaire 
dudit pont. 

L'etape 969 consiste a attendre pendant une duree suffisante 
predefinie ("time out" en terminologie anglo-saxonne) afin que tout peripherique 

10 utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
peripherique "distant" considere ce descripteur de chemin comme obsolete. En 
consequence, le peripherique doit par exemple regenerer un paquet de 
resolution d'adresse avant de pouvoir reprendre toute communication. 
L'etape 952 est ensuite executee. 

15 II convient de remarquer que lorsqu'un pont relie entre elles deux 

parties d'un reseau, deux longueurs d'identificateurs differentes peuvent etre 
determinees respectivement pour les deux equipements d'interconnexion ou 
"portals" du pont considere en fonction de deux caracteristiques respectivement 
propres a chacune desdites deux parties du reseau. 

20 Ainsi, dans un tel cas de figure, le marqueur qui delimite deux 

champs d'informations d'identification, respectivement du chemin a parcourir et 
parcouru par le paquet de donnees, voit sa taille ou longueur varier en 
consequence, afin que la difference de taille ou longueur entre les deux 
identificateurs des deux equipements d'interconnexion ou "portals" n'ait pas 

25 d'incidence sur la longueur totale du champ constitue du marqueur et des deux 
champs d'informations d'identification qui doit etre fixe. 

Dans la description qui precede faite en reference aux figures 18 
et 19, il vient d'etre explique que Ton adapte la longueur d'un identificateur ou 
label de routage au niveau d'un equipement d'interconnexion en fonction de 

30 caracteristique(s) propre(s) a une partie du reseau a laquelle est relie ledit 
equipement, et d'au moins une caracteristique du reseau (ERW) et que Ton 
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affecte un identificateur ayant cette longueur adaptee a au moins un 
equipement d'interconnexion relie a cette partie du reseau. 

Ceci permet notamment d'utiliser plus efficacement qu'auparavant 
les ressources en identificateurs de routage au niveau d'un bus auquel sont 
5 relics plusieurs equipements d'interconnexion. 

Les figures 20 et 21 represented respectivement les algorithmes 
d'un procede de determination d'identificateurs de ponts ou labels de routage 
analogues aux algorithmes des figures 18 et 19 mais qui sont, cette fois, mis en 
ceuvre au niveau d'un pont quelconque du reseau, ledit pont reliant une 
10 premiere partie du reseau a une deuxieme partie dudit reseau. 

Toutefois, dans ces algorithmes dont les etapes conservent les 
memes references que ceux des figures 18 et 19, il convient de noter que les 
etapes sont identiques a celles des figures 18 et 19 sauf en ce qui conceme les 
etapes respectives 901 (fig 20) et 951 (fig 21) au cours desquelles les ponts 
15 quefconques du reseau ne determinent pas la caracteristique ERW du reseau. 

On notera egalement que le dispositif de determination d'un 
identificateur de pont selon I'invention peut etre assimile au pont lui meme ou 
etre realise uniquement par I'unite de calcul et les memoires de stockage ROM 
et RAM contenant I'algorithme dont I'execution par I'unite de calcul permet la 
20 mise en ceuvre du procede selon I'invention. 
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REVINDICATIONS 



5 1. Procede de determination d'au moins un identificateur d'au 

moins un pont (60, 61 , 62, 63, 64, 65, 66, 67) reliant au moins une premiere 
partie d'un reseau (1, 10) a au moins une deuxieme partie dudit reseau, 
caracterise en ce que ledit procede comporte les etapes suivantes : 

- determination d'au moins une caracteristique (ERW) du reseau, 
10 - determination d'au moins une caracteristique de ladite au moins 

une premiere partie du reseau (1 , 10) a laquelle ledit pont est relie, 

-determination d'au moins une longueur d'au moins un 
identificateur (76, 77, 78, 79) associe a ladite au moins une premiere partie du 
reseau (1, 10) en fonction de ladite au moins une caracteristique de cette 
1 5 premiere partie et de ladite au moins une caracteristique (ERW) du reseau, 

- affectation d'au moins un identificateur ayant une longueur qui 
est celle venant d'etre determinee a au moins un pont (76, 77, 78, 79) relie a 
ladite au moins une premiere partie du reseau (1 , 10). 

2. Procede selon la revendication 1, caracterise en ce qu'au 
20 moins un identificateur (76, 77, 78, 79) est affecte audit pont (60, 61, 62, 63, 

64, 65, 66, 67) reliant lesdites premiere et deuxieme parties du reseau (1 , 10). 

3. Procede selon la revendication 2, caracterise en ce que, ledit 
pont (60, 61, 62, 63, 64, 65, 66, 67) comportant au moins deux portions reliees 
chacune auxdites au moins deux parties du reseau (1, 10), au moins un 

25 identificateur (76, 77, 78, 79) est affecte a chacune desdites au moins deux 
portions. 

4. Procede selon Tune des revendications 1 a 3, caracterise en 
ce que ledit pont (60, 61 , 62, 63, 64, 65, 66, 67) est relie a au moins un bus de 
communication serie (51, 52, 53, 54, 55, 56, 57, 58, 59). 
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5. Precede selon les revendications 3 et 4, caracterise en ce que 
chaque identificateur (76, 77, 78, 79) est unique pour un bus de communication 
serie donne (51, 52, 53, 54, 55, 56, 57, 58, 59). 

6. Procede selon I'une des revendications 1 a 5, caracterise en 
5 ce que I'etape de determination (903, 904) d'au moins une caracteristique de 

ladite au moins une premiere partie du reseau (1, 10) consiste a determiner son 
debit binaire. 

7. Procede selon I'une des revendications 1 a 6, caracterise en 
ce que I'etape de determination (953, 954) d'au moins une caracteristique de 

10 ladite au moins une premiere partie du reseau (1, 10) consiste a determiner le 
nombre de ponts (60, 61, 62, 63, 64, 65, 66, 67) relies a celle-ci. 

8. Procede selon I'une des revendications 1 a 7, caracterise en 
ce que I'etape d'affectation d'au moins un identificateur (76, 77, 78, 79) est 
effectuee pour chaque pont (60, 61, 62, 63, 64, 65, 66, 67) relie a ladite au 

15 moins une premiere partie du reseau (1 , 10). 

9. Procede selon la revendication 7, caracterise en ce que 
I'etape d'affectation d'au moins un identificateur (76, 77, 78, 79) est effectuee 
pour un nombre predetermine de ponts (60, 61, 62, 63, 64, 65, 66, 67) relies a 
ladite au moins une premiere partie du reseau (1, 10). 

20 10. Procede selon la revendication 9, caracterise en ce que le 

nombre maximal (MBNB) predetermine de ponts est egal a (2 ERW -i)™ id,WERW 
ou max-width represente le nombre de bits maximal pour coder un 
identificateur sur le reseau. 

11. Procede selon I'une des revendications 1 a 10, caracterise en 
25 ce que la caracteristique (ERW) du reseau correspond a la plus petite longueur 

possible d'identificateur de pont dans le reseau. 

12. Procede selon la revendication 11, caracterise en ce que la 
longueur dudit au moins un identificateur associe a ladite au moins une 
premiere partie du reseau est egale a un multiple de la plus petite longueur 

30 d'identificateur (ERW). 
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13. Procede selon Tune des revendications 1 a 12, caracterise en 
ce qu'il comporte une etape d'ajustement, en fonction de la caracteristique 
(ERW) du reseau, de la longueur d'un marqueur delimitant, dans un paquet de 
donnees transfere dans le reseau, un premier champ d'informations 

5 d'identification du chemin a parcourir par ledit paquet dans le reseau d'un 
deuxieme champ d'informations d'identification du chemin parcouru par ce 
paquet. 

14. Precede selon les revendications 11 et 13, caracterise en que 
la longueur du marqueur est ajustee a la plus petite longueur (ERW). 

10 15. Procede selon la revendication 13 ou 14, caracterise en ce 

que le marqueur (200, 205, 210, 235) comporte une suite predeterminee 
de bits. 

16. Procede selon la revendication 15, caracterise en ce que 
chaque pont (60, 61, 62, 63, 64, 65, 66, 67) relie a ladite au moins une 

15 premiere partie du reseau se voit affecter au moins un identificateur sous la 
forme d'une suite de bits choisie parmi un ensemble de valeurs ne contenant 
pas la suite predeterminee de bits correspondant au marqueur. 

17. Procede selon les revendications 12 et 13, caracterise en ce 
que ledit procede comporte une etape d'identification du marqueur dans un 

20 paquet de donnees transfere dans le reseau, les deux champs d'informations 
d'identification de chemin ainsi que le marqueur etant representes sous la 
forme d'une serie de bits consecutifs et ladite etape d'identification dudit 
marqueur parmi cette serie de bits comportant, plus particulierement, une etape 
de lecture des bits groupes suivant une longueur egale a un multiple entier de 

25 la caracteristique ERW. 

18. Procede selon Tune des revendications 1 a 17, caracterise en 
ce que ledit paquet de donnees comporte au moins deux champs 
d'informations (80, 81) dits d'identification du chemin respectivement a 
parcourir et parcouru par ledit paquet de donnees, lesdits au moins deux 

30 champs d'information ayant chacun une longueur donnee, ledit procede 
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comportant les etapes suivantes lors du transfert dudit paquet de donnees a 
travers ledit pont (60, 61 , 62, 63, 64, 65, 66, 67) : 

- suppression d'au moins une premiere information d'au moins un 
premier champ d 'informations (80) , reduisant ainsi la longueur dudit premier 
5 champ d'informations d'une longueur correspondant a celle de ladite premiere 
information, 

ajout d'au moins une deuxieme information dans au moins un 
deuxieme champ d'informations (81), augmentant ainsi la longueur dudit 
deuxieme champ d'informations d'une longueur correspondant a celle de ladite 
10 deuxieme information. 

19. Procede selon la revendication 18, caracterise en ce que le 
paquet de donnees comporte deux extremites opposees et lesdits au moins 
deux champs d'informations (80, 81) sont situes a une meme extremite dudit 
paquet de donnees. 

15 20. Procede selon la revendication 18 ou 19, caracterise en ce 

que le paquet de donnees comporte un troisieme champ d'informations dit 
marqueur (200, 205, 210, 235) qui delimite les premier et deuxieme champs 
d'informations I'un par rapport a I'autre. 

21. Procede selon la revendication 20, caracterise en ce que le 
20 marqueur (200, 205, 210, 235) comporte une suite predetermine de bits. 

22. Procede selon la revendication 21, caracterise en ce que le 
marqueur (200, 205, 210, 235) comporte une suite consecutive de bits ayant 
tous un meme etat. 

23. Procede selon la revendication 22, caracterise en ce que le 
25 marqueur (200, 205, 210, 235) comporte une suite consecutive de bits a 1 . 

24. Procede selon I'une des revendications 20 a 23, caracterise 
en ce qu'il comporte, lors du transfert dudit paquet de donnees a travers ledit 
pont, une etape de decalage des premier, deuxieme et troisieme champs 
d'informations entre les etapes de suppression et d'ajout d'informations. 
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25. Procede selon Tune des revendications 20 a 24, caracterise 
en ce que la longueur totale des premier, deuxieme et troisieme champs est 
fixe. 

26. Procede selon I'une des revendications 17 a 25, caracterise 
5 en ce qu'il comporte, lors du transfert dudit paquet de donnees a travers ledit 

pont, une etape de comparaison de la longueur de Tun des premier et 
deuxieme champs d'informations d'identification du paquet regu de ladite au 
moins une premiere partie du reseau (1, 10) avec la longueur du meme champ 
du paquet transmis sur ladite au moins une deuxieme partie du reseau (1, 10). 

10 27. Procede selon I'une des revendications 20 a 25, caracterise 

en ce que lorsque la longueur de Tun des premier et deuxieme champs 
d'informations d'identification du paquet regu de ladite au moins une premiere 
partie du reseau (1, 10) est differente de la longueur du meme champ du 
paquet transmis sur ladite au moins une deuxieme partie du reseau (1, 10), 

15 ledit procede comporte une etape de modification de la longueur du troisieme 
champ du paquet a transmettre. 

28. Procede selon la revendication 27, caracterise en ce que la 
longueur de Tun des premier et deuxieme champs d'informations d'identification 
du paquet regu de ladite au moins une premiere partie du reseau (1, 10) est 

20 egale a la longueur du meme champ du paquet transmis sur ladite au moins 
une deuxieme partie. 

29. Procede selon I'une des revendications 17 a 28, caracterise 
en ce que lesdits premier et deuxieme champs d'informations contiennent des 
informations relatives audit au moins un identificateur (76, 77, 78, 79) du ou 

25 des ponts (60, 61, 62, 63, 64, 65, 66, 67) disposes sur le chemin du paquet de 
donnees dans le reseau (1, 10). 

30. Procede selon la revendication 29, caracterise en ce que ledit 
premier champ d'informations contient des informations relatives audit au 
moins un identificateur (76, 77, 78, 79) du ou des ponts (60, 61, 62, 63, 64, 65, 

30 66, 67) disposes sur le chemin a parcourir par le paquet de donnees dans le 
reseau (1,10). 
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31. Precede selon la revendication 30, caracterise en ce que 
ladite au moins une premiere information supprimee dudit au moins un premier 
champ d'informations correspond audit au moins un identificateur (76, 77, 78, 
79) dudit pont (60, 61 , 62, 63, 64, 65, 66, 67) considere. 

32. Procede selon la revendication 31, caracterise en ce que, 
lorsque le pont (60, 61, 62, 63, 64, 65, 66, 67) considere comporte au moins 
deux portions reliees chacune auxdites au moins deux parties du reseau (1,10) 
et qu'au moins un identificateur (76, 77, 78, 79) est attribue a chacune desdites 
au moins deux portions, ladite au moins une premiere information supprimee 
dudit au moins un premier champ d'informations correspond audit au moins un 
identificateur (76, 77, 78, 79) de la portion du pont qui est reliee a la partie du 
reseau (1, 10) par laquelle le paquet de donnees parvient audit pont (60, 61, 
62, 63, 64, 65, 66, 67). 

33. Procede selon I'une des revendications 29 a 32, caracterise 
en ce que ledit deuxieme champ d'informations contient des informations 
relatives audit au moins un identificateur (76, 77, 78, 79) du ou des ponts (60, 

61, 62, 63, 64, 65, 66, 67) disposes sur le chemin parcouru par le paquet de 
donnees dans le reseau (1, 10). 

34. Procede selon la revendication 33, caracterise en ce que 
ladite au moins une deuxieme information ajoutee audit au moins un deuxieme 
champ d'informations correspond audit au moins un identificateur (76, 77, 78, 
79) dudit pont (60, 61, 62, 63, 64, 65, 66, 67) considere. 

35. Procede selon la revendication 34, caracterise en ce que, 
lorsque le pont (60, 61, 62, 63, 64, 65, 66, 67) considere comporte au moins 
deux portions reliees chacune auxdites au moins deux parties du reseau (1, 10) 
et qu'au moins un identificateur (76, 77, 78, 79) est attribue a chacune desdites 
au moins deux portions, ladite au moins une deuxieme information ajoutee 
audit au moins un deuxieme champ d'informations correspond audit au moins 
un identificateur (76, 77, 78, 79) de la portion du pont qui est reliee a la partie 
du reseau (1, 10) par laquelle le paquet de donnees quitte ledit pont (60, 61, 

62, 63, 64, 65, 66, 67). 
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36. Precede de determination d'au moins un identificateur d'au 
moins un pont (60, 61, 62, 63, 64, 65, 66, 67) reliant au moins une premiere 
partie d'un reseau (1, 10) a au moins une deuxieme partie dudit reseau, 
caracterise en ce que ledit procede comporte les etapes suivantes : 

5 - determination d'au moins une caracteristique de ladite au 

moins une premiere partie du reseau (1, 10) a laquelle ledit pont est relie, 

determination d'au moins une longueur (BRW) d'au moins un 
identificateur (76, 77, 78, 79) associe a ladite au moins une premiere partie du 
reseau (1, 10) en fonction de ladite au moins une caracteristique de cette 
10 premiere partie et d'au moins une caracteristique (ERW) du reseau, 

affectation d'au moins un identificateur ayant une longueur 
qui est celle venant d'etre determinee a au moins un pont (76, 77, 78, 79) relie 
a ladite au moins une premiere partie du reseau (1, 10). 

37. Dispositif de determination d'au moins un identificateur (76, 
15 77, 78, 79) d'au moins un pont (60, 61, 62, 63, 64, 65, 66, 67) reliant au moins 

une premiere partie d'un reseau (1, 10) a au moins une deuxieme partie dudit 
reseau (1, 10), caracterise en ce que ledit dispositif comporte : 

- des moyens de determination d'au moins une caracteristique 
(ERW) du reseau, 

20 - des moyens de determination d'au moins une caracteristique de 

ladite au moins une premiere partie du reseau (1, 10) a laquelle ledit pont (60, 
61, 62, 63, 64, 65, 66, 67) est relie, 

- des moyens de determination d'au moins une longueur d'au 
moins un identificateur (76, 77, 78, 79) associe a ladite au moins une premiere 

25 partie du reseau (1, 10) en fonction de ladite au moins une caracteristique de 
cette premiere partie et de ladite au moins une caracteristique (ERW) du 
reseau, 

- des moyens d'affectation d'au moins un identificateur (76, 77, 78, 
79) ayant une longueur qui est celle venant d'etre determinee a au moins un 

30 pont relie a ladite au moins une premiere partie du reseau (1 , 10). 
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38. Dispositif selon la revendication 37, caracterise en ce qu'au 
moins un identificateur est affecte audit pont (60, 61, 62, 63, 64, 65, 66, 67) 
reliant lesdites premiere et deuxieme parties du reseau (1, 10). 

39. Dispositif selon la revendication 38, caracterise en ce que ledit 
pont (60, 61, 62, 63, 64, 65, 66, 67) comporte au moins deux portions reliees 
chacune auxdites au moins deux parties du reseau (1, 10). 

40. Dispositif selon la revendication 39, caracterise en ce qu'au 
moins un identificateur (76, 77, 78, 79) est affecte a chacune desdites au moins 
deux portions. 

41 . Dispositif selon la revendication 39 ou 40, caracterise en ce 
que chaque portion du pont (60, 61, 62, 63, 64, 65, 66, 67) comporte des 
moyens de suppression d'au moins une premiere information d'au moins un 
premier champ d'informations et des moyens d'ajout d'au moins une deuxieme 
information dans au moins un deuxieme champ d'informations. 

42. Dispositif selon Tune des revendications 39 a 41, caracterise 
en ce que chaque portion du pont (60, 61, 62, 63, 64, 65, 66, 67) comporte des 
moyens de lecture de ladite au moins une premiere information dudit premier 
champ d'informations. 

43. Dispositif selon I'une des revendications 37 a 42, caracterise 
en ce que ledit pont est relie a au moins un bus de communication serie (51 , 
52, 53, 54, 55, 56, 57, 58, 59). 

44. Dispositif selon les revendications 40 et 43, caracterise en ce 
que chaque identificateur est unique pour un bus de communication serie 
donne(51, 52, 53, 54, 55, 56, 57, 58, 59). 

45. Dispositif selon la revendication 43 ou 44, caracterise en ce 
que les bus de communication serie (51 , 52, 53, 54, 55, 56, 57, 58, 59) sont 
conformes a la norme IEEE 1394. 

46. Dispositif selon I'une des revendications 37 a 45, caracterise 
en ce que les moyens de determination d'au moins une caracteristique de 
ladite au moins une premiere partie du reseau (1, 10) comportent des moyens 
de determination de son debit binaire. 
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47. Dispositif selon I'une des revendications 37 a 46, caracterise 
en ce que les moyens de determination d'au moins une caracteristique de 
ladite au moins une premiere partie du reseau (1, 10) comportent des moyens 
de determination du nombre de ponts (60, 61, 62, 63, 64, 65, 66, 67) relies a 

5 celle-ci. 

48. Dispositif selon la revendication 47, caracterise en ce que le 
nombre maximal (MBNB) predetermine de ponts est egal a (2 ERW -1 ) ma *- width/ERW , 
ou max-width represente le nombre de bits maximal pour coder un 
identificateur sur le reseau. 

10 49. Dispositif selon I'une des revendications 37 a 48, caracterise 

en ce que la caracteristique (ERW) du reseau correspond a la plus petite 
longueur possible d'identificateur de pont dans le reseau. 

50. Dispositif selon la revendication 49, caracterise en ce que la 
longueur dudit au moins un identificateur associe a ladite au moins une 

15 premiere partie du reseau est egale a un multiple de la plus petite longueur 
d'identificateur (ERW). 

51. Dispositif selon I'une des revendications 37 a 50, caracterise 
en ce qu'il comporte des moyens d'ajustement, en fonction de la caracteristique 
(ERW) du reseau, de la longueur d'un marqueur delimitant, dans un paquet de 

20 donnees transfere dans le reseau, un premier champ d'informations 
d'identification du chemin a parcourir par ledit paquet dans le reseau d'un 
deuxieme champ d'informations d'identification du chemin parcouru par ce 
paquet. 

52. Dispositif selon les revendications 49 et 51 , caracterise en ce 
25 que la longueur du marqueur est ajustee a la plus petite longueur (ERW). 

53. Dispositif selon la revendication 51 ou 52, caracterise en ce 
que le marqueur (200, 205, 210, 235) comporte une suite predetermined de 
bits. 

54. Dispositif selon la revendication 53, caracterise en ce que 
30 chaque pont (60, 61, 62, 63, 64, 65, 66, 67) relie a ladite au moins une 

premiere partie du reseau se voit affecte au moins un identificateur sous la 
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forme d'une suite de bits choisie parmi un ensemble de valeurs ne contenant 
pas la suite predeterminee de bits correspondant au marqueur. 

55. Dispositif selon les revendications 50 et 51, caracterise en ce 
que ledit procede comporte des moyens d'identification du marqueur dans un 
paquet de donnees transfere dans le reseau, les deux champs d'informations 
d'identification de chemin ainsi que le marqueur etant represent.es sous la 
forme d'une serie de bits consecutifs et lesdits moyens d'identification dudit 
marqueur parmi cette serie de bits comportant, plus particulierement, des 
moyens de lecture des bits groupes suivant une longueur egale a un multiple 
entier de la caracteristique (ERW). 

56. Dispositif selon Tune des revendications 37 a 55, caracterise 
en ce que ledit paquet de donnees comporte au moins deux champs 
d'informations (80, 81) dits d'identification du chemin respectivement a 
parcourir et parcouru par ledit paquet de donnees, lesdits au moins deux 
champs d'information ayant chacun une longueur donnee, ledit dispositif 
comportant : 

-des moyens de suppression d'au moins une premiere 
information d'au moins un premier champ d'informations, reduisant ainsi la 
longueur dudit premier champ d'informations (80) d'une longueur 
correspondant a celle de ladite premiere information, 

- des moyens d'ajout d'au moins une deuxieme information dans 
au moins un deuxieme champ d'informations (81), augmentant ainsi la longueur 
dudit deuxieme champ d'informations d'une longueur correspondant a celle de 
ladite deuxieme information. 

57. Dispositif selon la revendication 56, caracterise en ce que le 
paquet de donnees comporte deux extremites opposees et lesdits au moins 
deux champs d'informations (80, 81) sont situes a une meme extremite dudit 
paquet de donnees. 

58. Dispositif selon la revendication 56 ou 57, caracterise en ce 
que le paquet de donnees comporte un troisieme champ d'informations dit 
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marqueur (200, 205, 210, 235) qui delimite les premier et deuxieme champs 
d'informations I'un par rapport a I'autre. 

59. Dispositif selon la revendication 58, caracterise en ce que le 
marqueur (200, 205, 210, 235) a une longueur au moins egale au nombre de 

5 bits necessaire pour coder un identificateur (76, 77, 78, 79) dudit pont dans I'un 
des champs d'informations. 

60. Dispositif selon la revendication 58 ou 59, caracterise en ce 
qu'il comporte des moyens de decalage des premier, deuxieme et troisieme 
champs d'informations. 

10 61. Dispositif selon Tune des revendications 58 a 60, caracterise 

en ce que la longueur totale des premier, deuxieme et troisieme champs est 
fixe. 

62. Dispositif selon Tune des revendications 57 a 61, caracterise 
en ce qu'il comporte des moyens de comparaison de la longueur de I'un des 

1 5 premier et deuxieme champs d'informations d'identification du paquet regu de 
ladite au moins une premiere partie du reseau (1, 10) avec la longueur du 
meme champ du paquet transmis sur ladite au moins une deuxieme partie du 
reseau (1, 10). 

63. Dispositif selon Tune des revendications 58 a 62, caracterise 
20 en ce qu'il comporte des moyens de modification de la longueur du troisieme 

champ du paquet a transmettre. 

64. Dispositif selon la revendication 62 ou 63, caracterise en ce 
que la longueur de I'un des premier et deuxieme champs d'informations 
d'identification du paquet regu de ladite au moins une premiere partie du 

25 reseau (1 , 10) est egale a la longueur du meme champ du paquet transmis sur 
ladite au moins une deuxieme partie du reseau (1 , 10). 

65. Dispositif selon Tune des revendications 57 a 64, caracterise 
en ce que lesdits premier et deuxieme champs d'informations contiennent des 
informations relatives audit au moins un identificateur (76, 77, 78, 79) du ou 

30 des ponts disposes sur le chemin du paquet de donnees dans le reseau (1, 
10). 
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66. Dispositif selon la revendication 65, caracterise en ce que ledit 
premier champ d'informations contient des informations relatives audit au 
moins un identificateur (76, 77, 78, 79) du ou des ponts (60, 61 , 62, 63, 64, 65, 
66, 67) disposes sur le chemin a parcourir par le paquet de donnees dans le 

5 reseau (1, 10). 

67. Dispositif selon la revendication 66, caracterise en ce que 
ladite au moins une premiere information supprimee dudit au moins un premier 
champ d'informations correspond audit au moins un identificateur (76, 77, 78, 
79) dudit pont (60, 61 , 62, 63, 64, 65, 66, 67) considere. 

10 68. Dispositif selon la revendication 67, caracterise en ce que, 

lorsque le pont (60, 61, 62, 63, 64, 65, 66, 67) considere comporte au moins 
deux portions reliees chacune auxdites au moins deux parties du reseau (1,10) 
et qu'au moins un identificateur est affecte a chacune desdites au moins deux 
portions, ladite au moins une premiere information supprimee dudit au moins 

15 un premier champ d'informations correspond audit au moins un identificateur 
(76, 77, 78, 79) de la portion du pont (60, 61, 62, 63, 64, 65, 66, 67) qui est 
reliee a la partie du reseau (1, 10) par laquelle le paquet de donnees parvient 
audit pont. 

69. Dispositif selon Tune des revendications 57 a 68, caracterise 
20 en ce que ledit deuxieme champ d'informations contient des informations 

relatives audit au moins un identificateur (76, 77, 78, 79) du ou des ponts (60, 
61, 62, 63, 64, 65, 66, 67) disposes sur le chemin parcouru par le paquet de 
donnees dans le reseau (1 , 10). 

70. Dispositif selon la revendication 69, caracterise en ce que 
25 ladite au moins une deuxieme information ajoutee audit au moins un deuxieme 

champ d'informations correspond audit au moins un identificateur dudit pont 
(60, 61, 62, 63, 64, 65, 66, 67) considere. 

71. Dispositif selon la revendication 70, caracterise en ce que, 
lorsque le pont considere (60, 61, 62, 63, 64, 65, 66, 67) comporte au moins 

30 deux portions reliees chacune auxdites au moins deux parties du reseau (1 , 10) 
et qu'au moins un identificateur est attribue a chacune desdites au moins deux 
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portions, ladite au moins une deuxieme information ajoutee audit au moins un 
deuxieme champ d'informations correspond audit au moins un identificateur 
(76, 77, 78, 79) de la portion du pont (60, 61, 62, 63, 64, 65, 66, 67) qui est 
reliee a la partie du reseau (1,10) par laquelle le paquet de donnees quitte ledit 
pont. 

72. Dispositif de determination d'au moins un identificateur (76, 

77, 78, 79) d'au moins un pont (60, 61, 62, 63, 64, 65, 66, 67) reliant au moins 
une premiere partie d'un reseau (1, 10) a au moins une deuxieme partie dudit 
reseau (1, 10), caracterise en ce que ledit dispositif comporte : 

des moyens de determination d'au moins une caracteristique 
de ladite au moins une premiere partie du reseau (1, 10) a laquelle ledit pont 
(60, 61, 62, 63, 64, 65, 66, 67) est relie, 

des moyens de determination d'au moins une longueur d'au 
moins un identificateur (76, 77, 78, 79) associe a ladite au moins une premiere 
partie du reseau (1, 10) en fonction de ladite au moins une caracteristique de 
cette premiere partie et d'au moins une caracteristique (ERW) du reseau, 

des moyens d'affectation d'au moins un identificateur (76, 77, 

78, 79) ayant une longueur qui est ceile venant d'etre determinee a au moins 
un pont relie a ladite au moins une premiere partie du reseau (1, 10). 

73. Pont (60, 61, 62, 63, 64, 65, 66, 67) reliant au moins deux 
parties d'un reseau (1, 10) de communication de paquet de donnees entre 
elles, caracterise en ce que ledit pont comporte un dispositif de determination 
d'au moins un identificateur (76, 77, 78, 79) d'au moins un pont selon I'une des 
revendications 37 a 72. 

74. Appareil de traitement de donnees, caracterise en ce qu'il 
comporte un pont selon la revendication 73. 

75. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est une imprimante. 

76. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un serveur. 
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77. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un ordinateur. 

78. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un telecopieur. 

5 79. Appareil selon la revendication 74, caracterise en ce que ledit 

appareil est un scanner. 

80. Appareil selon la revendication 74, caracterise en ce que iedit 
appareil est un magnetoscope. 

81. Appareil selon la revendication 74, caracterise en ce que ledit 
1 0 appareil est un decodeur. 

82. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un televiseur. 

83. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est une camescope. 

15 84. Appareil selon la revendication 74, caracterise en ce que ledit 

appareil est une camera numerique. 

85. Appareil selon la revendication 74, caracterise en ce que ledit 
appareil est un appareil photographique numerique. 

86. Reseau (1, 10) de communication de paquets de donnees 
20 comportant au moins deux parties reliees entre elles par au moins un pont (60, 

61, 62, 63, 64, 65, 66, 67), caracterise en ce que ledit pont est conforme a la 
revendication 73. 

87. Reseau (1, 10) selon la revendication 86, caract§ris§ en ce 
que chacune desdites au moins deux parties dudit reseau (1, 10) comporte au 

25 moins un bus de communication serie (51 , 52, 53, 5, 55, 56, 57, 58, 59) auquel 
est relie ledit pont (60, 61 , 62, 63, 64, 65, 66, 67). 

88. Reseau (1, 10) de communication de paquets de donnees 
comportant au moins deux parties reliees entre elles par au moins un pont (60, 
61, 62, 63, 64, 65, 66, 67), caracterise en ce que ledit reseau (1, 10) comporte 

30 un appareil de traitement de donnees selon Tune des revendications 74 a 85. 
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